Re: [PATCH net v5 0/3] macsec: Add support for VLAN filtering in offload mode

[Sabrina Dubroca <sd@queasysnail.net>]

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