On Fri, Oct 23, 2026 at 1:38 PM Luca Vizzarro <[email protected]> wrote:
> On 22/10/2026 18:29, Koushik Bhargav Nimoji wrote: > > > > > > On Thu, Oct 22, 2026 at 9:51 AM Luca Vizzarro <[email protected] > > <mailto:[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]> > > > <mailto:[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. > > 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 > After looking into it further, I've found the bug!. The setup for TRex never calls configure_ports() at all, instead letting TRex handle port bindings itself internally which leaves the port configurations in a stale state. I've added the configure_ports("tg", "dpdk") call to the setup method in trex.py and removed all manual port bindings and teardowns. I've tested the change and it works accurately on my end. I'll send out another version of my patch shortly. Thanks!
