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

On Mon, 24 Aug 2026 15:09:31 +0000 Cosmin Ratiu wrote:

On Mon, 2026-08-24 at 08:01 -0700, Jakub Kicinski wrote:

quoted

On Sun, 23 Aug 2026 11:31:03 -0400 Daniel Zahka wrote:  

quoted

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.