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

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

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:

quoted

@@ -72,6 +90,27 @@ name: psp

           Present when in associated namespace, absent when in
primary/host
           namespace.
         type: flag
+      -
+        name: vc-steer-cap
+        doc: |
+          Device can steer received traffic on the PSP
virtualization
+          cookie (VC). The VC is split into a 32b reserved part,
a 16b
+          queue ID the sender is asking the peer to send to, and
a 16b
+          queue ID granting the peer's own request. Steering
installs low
+          priority rules matching the latter, which win over the
RSS table
+          result. Only needed for the rx direction; granting a
peer's
+          request is just header generation and needs no device
support.
+        type: flag
+      -
+        name: vc-steer-ena
+        doc: |
+          Directions taking part in VC based queue steering.
Leave the
+          attribute out of a dev-set request to keep the current
setting.
+          Applies to associations created from then on, existing
ones keep
+          the setting they were created with.
+        type: u32
+        enum: vc-steer
+        enum-as-flags: true
   

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.

Cosmin.