Re: [PATCH net-next] net: dummy: add phony ndo_setup_tc stub

[Jakub Kicinski <kuba@kernel.org>]

On Wed, 10 Jun 2026 00:25:30 +0200 Florian Westphal wrote:
> Jakub Kicinski <kuba@kernel.org> wrote:
> > On Tue,  9 Jun 2026 16:28:09 +0200 Florian Westphal wrote:  
> > > Unlike netdevsim, dummy is a data sink so no capabilities (e.g.
> > > u32-style matcher, vport device redirects, PPPoE header push/pop etc).
> > > have to be implemented.  
> > 
> > If no "peer" is configured netdevsim is also a data sink.  
> 
> Yes, but you can configure peers.  And then this fake offload stub
> is a liar.
> 
> I would expect that offloads for netdevsim actually work, i.e.
> that a shaper shapes, that ets offload does delay packets and
> in case of flowtable that it will move skbs from one vport to
> another (if that was requested).
> 
> > We added netdevsim because dummy and veth started accumulating
> > "features" which were clearly just for test harnesses. Would be
> > great if we could stay the course and put whatever changes you
> > need in netdevsim, even if it requires some hacks.  
> 
> Is a lot more work.  I don't have time ATM to implement a u32-style
> packet matcher or a fake software flowtable.

There are no real requirements on how netdevsim behaves. The only
requirement is that there's an in-tree test that uses whatever
functionality is being added. So you can implement the features
to whatever depth you need for your current testing.

> > Is there anything fundamentally blocking the use of netdevsim?
> > Or is it just convenience (since netdevsim is a bit of a PITA
> > to create and establish the name of)?  
> 
> I played with netdevsim, aside from the above (i.e., I don't expect
> netdevsim to say 'offloaded' and then ignore all the offloaded
> commands...) the worst part is the naming and the behaviour when
> creating new devices while in a network namespace.  Test is spawned via
> 'unshare -n' -- I did not find a way to really extract the new device name
> reliably except via 'ip link'.

Yes :( we have some helpers in 
tools/testing/selftests/drivers/net/netdevsim/ethtool-common.sh
among other places but libraries are a PITA in ksft as well.

> I think thats solveable, so yes, I could make netdevsim lie instead.
> 
> But I don't think its the right thing to do.
> 
> If you disagree and think that this is fine I can retarget this to
> netdevsim, no problem.

Yes, I'd prefer netdevsim. If nothing else it lets us discard 
"security reports" by saying that nobody should have netdevsim 
loaded on a production system.