On Thu, Oct 22, 2026 at 9:51 AM Luca Vizzarro <[email protected]> wrote:
> On 20/10/2026 17:06, Koushik Bhargav Nimoji wrote: > > On Fri, Oct 16, 2026 at 12:28 PM Luca Vizzarro <[email protected] > > <mailto:[email protected]>> 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.
