Re: [RFC net-next 0/6] psp: use virt cookie as Rx steering hint

[Cosmin Ratiu <cratiu@nvidia.com>]

On Sun, 2026-08-23 at 13:48 -0400, Willem de Bruijn wrote:
> Jakub Kicinski wrote:
> > Hi!
> > 
> > This PoC series uses a field of the PSP header intended for tunnels
> > to auto-steer Rx traffic. Various attempts have been made at trying
> > to get Rx traffic to land close to the core where the application
> > runs.
> > By default RSS picks the Rx queue based on the flow hash.
> > I'm not going to cover all previous solutions in detail but broadly
> > - we have RFS in SW which looks on which CPU Tx happens and
> > backlogs
> > Rx packets there, it is quite efficient. aRFS is built on top
> > of RFS but tries to program flows into the NIC. Some NICs have
> > a "cache" and try to automatically remember the flow to queue
> > association.
> > 
> > All those solutions are entirely local to the receiver.
> > Ideally we would want the solution to look something like
> > TCP timestamp option - we send an opaque cookie to the peer,
> > and the peer echoes it back to us. Our NIC can steer based
> > on that echoed cookie.
> 
> Another option is to reverse RSS entropy. This requires knowledge of
> the RSS secret.
> 
> Especially with PSP, the outer UDP source port is defined as flow
> hash, so can be used for this.
> 
> Have the receiver compute a 4-tuple hash such that it knows the RSS
> block will select the intended queue. The only free variable here in
> general is the source port. Then communicate this preferred source
> port to the sender.

I was thinking of something along these lines as an alternative.
When initializing PSP for a connection, look at what the device uses
with .get_rxfh(), and find a value sport (either by linear algebra or
linear probing) such that the 4-tuple hash results in the desired
queue. This might require some non-trivial code changes to reimplement
the hashes in SW though, but it's local to this sport selection only.

psp_dev_encapsulate() and psp_write_headers() both conveniently already
have a sport argument, which is currently ignored, so plumbing this is
easy.

This would result in zero RX changes for driver implementors.

An easier alternative to avoid reverse engineering RSS hash
implementations would be to vary the desired sport across multiple
packets and until packets start coming to the desired queue. Presumably
this could converge to the desired queue in O(num_queues) TX packets +
acks. Maybe could be done with TCP keep alives at connection setup?

Cosmin.