Re: [RFC net-next 1/6] psp: steer Rx queues with the virtualization cookie

[Jakub Kicinski <kuba@kernel.org>]

On Mon, 24 Aug 2026 15:09:31 +0000 Cosmin Ratiu wrote:
> On Mon, 2026-08-24 at 08:01 -0700, Jakub Kicinski wrote:
> > On Sun, 23 Aug 2026 11:31:03 -0400 Daniel Zahka wrote:  
> > > On Sat Aug 22, 2026 at 6:55 PM EDT, Jakub Kicinski wrote:  
> > > Should vc-steer-ena be a connection level setting? Maybe it could
> > > go
> > > into rx-assoc. The way it's implemented here, the state is already
> > > per
> > > assoc.  
> > 
> > That's what I started with but then given the security implications
> > of the current simple design I could not think of a reason do
> > configure
> > this connection by connection. Besides the SW stack responsible for
> > security is likely somewhat orthogonal to steering configuration. 
> > Should have put this in the cover letter as well.  
> 
> I looked at implementing the current design in mlx5 and a per-assoc
> setting wouldn't be enough, because flipping this on requires device-
> level steering changes (basically adding num_queues steering rules).
> For device-level settings, we conveniently have the .set_config()
> callback. There's no per-assoc callbacks, but theoretically, we could
> detect the first use of VC-based steering and do things. Doesn't feel
> that clean though compared to device-level.

To be clear - the per-assoc would be in addition to the device level
setting. We'd have to enable the feature and then instead of
snapshoting the device config in psp_assoc_create() we'd have explicit
Netlink flags. We can do this later, the two flags I added here can be
thought of as "enable for all assocs", we can add "enable per-assoc"
device config later. Tho for Tx not echoing a request would be pure
spite...

I implemented the per-assoc things first but then I thought about
deploying this and really there's no reason to plumb this policy thru
Fizz/Thrift handshaking which creates assocs.