2026-03-24, 14:27:12 +0000, Cosmin Ratiu wrote: > On Mon, 2026-03-23 at 18:17 +0100, Sabrina Dubroca wrote: > > 2026-03-23, 09:32:43 -0700, Jakub Kicinski wrote: > > > On Mon, 23 Mar 2026 16:02:59 +0100 Sabrina Dubroca wrote: > > > > 2026-03-23, 14:42:00 +0000, Cosmin Ratiu wrote: > > > > > On Mon, 2026-03-23 at 15:28 +0100, Sabrina Dubroca wrote: > > > > > > Why not? Being able to test without accessing real HW is > > > > > > still > > > > > > useful. > > > > > > > > > > > The tests now send macsec traffic over VLANs and nsim, it's > > > > > just that > > > > > nsim doesn't deal with VLAN filters at all and there are no > > > > > stubbed > > > > > vlan filters in debugfs, since real hw doesn't have that > > > > > interface. > > > > > > > > Since netdevsim doesn't deal with VLAN filters at all, the "tests > > > > should be written so that they can run both against ``netdevsim`` > > > > and > > > > a real device" bit of the docs doesn't fully apply here? > > > > > > > > Anyway, I think the original tests had value, even if they're > > > > more > > > > limited in some ways than traffic tests. HW/driver behavior could > > > > be > > > > hiding problems in the stack with VLAN propagation, those simpler > > > > tests don't have that risk. > > > > > > To be clear running the HW test without NETIF= should provide > > > similar functionality to what the old tests could do. It's entirely > > > okay to add netdevsim-specific subtests/test cases or asserts. > > > > > > Is there anything specific that you'd like to be tested? > > > > In v2/v3, nsim was exposing a debugfs file that contained the list of > > VLAN filters on that interface, and the selftest was grepping through > > that file to check if the correct entry was added/removed after each > > operation. I see that as testing the actual propagation of filters, > > while the traffic tests check the visible behavior of > > stack+driver+HW, > > which may not be correlated to actual propagation. > > > > > Let's not make this about HW tests vs nsim-only tests. > > > > That was not my intention. But since nsim doesn't currently implement > > VLAN filters, it seems running the HW test on nsim doesn't test > > anything at all. > > > > The problem with using the nsim-only VLAN filter debugfs is that it's a > test-only interface for figuring out a property of the stack.
That's the whole point of netdevsim. > Real HW > doesn't have that interface and thus the tests actually have to > generate traffic to ensure VLANs are propagated. > > The new VLAN tests don't actually ensure anything on nsim, given that > it doesn't support VLANs. But on real HW they do - without the last > patch, the new tests fail on any hw supporting VLANs and MACsec. Well, they ensure that something in the stack+driver+HW combination is doing something that lets traffic go through. It's useful, but we can learn something extra from netdevsim. > Adding back the nsim debugfs file and test assertions guarded by "if > cfg._ns" would ensure filter propagation correctness, but would feel > non-Pythonic and a little hacky given that the same assertion can't > work on real HW. I think that's fine. The tests are anyway python wrappers around iproute commands, it's neither "Pythonic" nor pretty. Jakub, any objection? > So what would you like to happen? Bring back nsim patches + nsim- > specific test assertions? Yes, IMO that would be best. -- Sabrina
