[RFC PATCH] dts: resolve trex driver binding issue

Luca Vizzarro Luca.Vizzarro at arm.com
Fri Oct 23 19:38:28 CEST 2026


On 22/10/2026 18:29, Koushik Bhargav Nimoji wrote:
> 
> 
> On Thu, Oct 22, 2026 at 9:51 AM Luca Vizzarro <Luca.Vizzarro at arm.com 
> <mailto:Luca.Vizzarro at arm.com>> wrote:
> 
>     On 20/10/2026 17:06, Koushik Bhargav Nimoji wrote:
>      > On Fri, Oct 16, 2026 at 12:28 PM Luca Vizzarro
>     <Luca.Vizzarro at arm.com <mailto:Luca.Vizzarro at arm.com>
>      > <mailto:Luca.Vizzarro at arm.com <mailto:Luca.Vizzarro at arm.com>>> wrote:
>      >
>      >      > +        if (
>      >      > +            ctx.topology.type is not LinkTopology.NO_LINK
>      >      > +            and testsuite_type is not TestSuiteType.CRYPTO
>      >      > +        ):
>      >      > +            if testsuite_type == TestSuiteType.FUNC:
>      >      > +                required_tg, other_tg = ctx.func_tg,
>     ctx.perf_tg
>      >      > +            else:
>      >      > +                required_tg, other_tg = ctx.perf_tg,
>     ctx.func_tg
>      >      > +
>      >      > +            if other_tg and other_tg.is_setup:
>      >      > +                other_tg.teardown()
>      >      > +
>      >      > +                if testsuite_type == TestSuiteType.FUNC and
>      >     ctx.tg_node:
>      >      > +                    for port in ctx.topology.tg_ports:
>      >      > +
>      >     ctx.tg_node.main_session.bind_ports_to_driver([port],
>      >     port.config.os_driver)
>      >
>      >     I am a bit confused why this happens here. The driver to be
>     bound to
>      >     should be governed by the TG that uses such ports. Could be
>     os_driver,
>      >     could be dpdk_driver, regardless of Scapy and TRex.
>      >
>      > This section exists because of how scapy and TRex handle port driver
>      > bindings. TRex automatically binds ports to the required driver when
>      > setup, but scapy requires it to be done manually. That's why if
>     the next
>      > test suite to be tested is a functional test suite, the TG ports are
>      > rebound to the os_driver manually here.
> 
>     So I think the original intention here was that TRex would
>     exceptionally
>     change the driver as the normal behaviour was that the TG was not going
>     to be subject to driver binding. Therefore what would make sense is for
>     the TG to control driver binding accordingly. So if Scapy is setup that
>     it would be up to Scapy to "bind to kernel drivers" if needed. What do
>     you think?
> 
> 
> I think you're definitely right here, it should be up to the TG to take 
> care of port bindings instead of doing it manually. Scapy currently does 
> take care of that, but there's an issue with DTS's internal state being 
> out of date after rebinding to the kernel driver. As a workaround for 
> this, I have added a teardown method to trex.py that rebinds ports to 
> the kernel driver before scapy is set up. I will send out a version 
> shortly that reflects these changes, thanks for bringing this up.

So I think the problem with the state is because you are not using 
Topology which is the ports manager/owner. Even if `main_session` is 
public, it's an internal API which use should be limited to some. If you 
look at the setup of Scapy:

     def setup(self, topology: Topology) -> None:
         super().setup(topology)
         topology.configure_ports("tg", "kernel")

What I expect to see in the Trex class is:

     def setup(self, topology: Topology) -> None:
         super().setup(topology)
         topology.configure_ports("tg", "dpdk")

If this doesn't work as intended, then there is a bug that needs resolving.

Luca


More information about the dev mailing list