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

[Cosmin Ratiu <cratiu@nvidia.com>]

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:
> > > @@ -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.