Re: [net-next, v3 1/2] psp: Support for transmit on logical device when the underlying transport device supports PSP.

[Willem de Bruijn]

Jakub Kicinski wrote:
> On Sat, 28 Feb 2026 14:46:28 -0500 Willem de Bruijn wrote:
> > Jakub Kicinski wrote:
> > > On Thu, 26 Feb 2026 10:46:53 -0800 Kiran Kella wrote:  
> > > > This is achieved by propagating the psp_dev from the lower device
> > > > to the upper devices in the device stack via a netdevice notifier.
> > > > The lowest device owns the psp_dev pointer while the upper devices
> > > > just borrow the pointer. When the lower device is unlinked, the
> > > > borrowed pointer is cleared in the upper device.
> > > > Assumption being that psp_dev is set on the lowest device before
> > > > any upper devices are stacked on that lowest device.  
> > > 
> > > As I mentioned in the other thread I'd like to establish some clear
> > > expectation on where psd propagates automatically and where it doesn't.
> > > I don't want to see a stream of patches that say "fix propagating PSP
> > > onto X upper". And conversely report saying "PSP got propagated but
> > > it doesn't actually work" (macvlan in bridge mode etc).
> > > 
> > > Hence my preference was to require the user who created the device
> > > to propagate PSP. Willem, WDYT?  
> > 
> > Can you give a bit more detail what you have in mind?
> > 
> > An explicit user (netlink) API to associate a psp_dev with a
> > net_device?
> 
> Yes:
> https://lore.kernel.org/all/20260224002410.1553838-7-weibunny@xxxxxx/

I see. Yes, fair to ask for an explicit sensible policy.

It would be nice if PSP could transparently be enabled on upper
devices, similar to dev->features.

But this quickly runs into practical questions like when and how can a
bonding device with multiple independent lower devices support PSP?

dev->features also has type specific carve-outs for upper types, such
as vlan_features and hw_enc_features. We probably don't want to
introduce the same for PSP.