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

Jakub Kicinski wrote:

PSP leaves the 64b virtualization cookie undefined in transport mode.
Put it to use: let both ends of a connection tell each other which Rx
queue they want traffic on, so that a flow can be pinned to a queue
without the receiver having to install a per-flow steering rule, and
without the sender having to know anything about the receiver's queue
layout. The cookie holds a queue ID the sender is asking the peer to
send to ("req") and the queue ID the peer last asked for, granted
("dst"). Each ID gets a 32b word of the cookie to itself and uses only
the low half of it, so that either can grow to 32b later without the
fields moving.

The two directions are configured separately:

 * rx asks peers to send to the queue paired with the flow's Tx queue,
   so traffic this host receives gets steered. The receiver installs one
   low priority rule per Rx queue matching "dst", which wins over RSS,
   so this needs vc-steer-cap.
 * tx grants the requests peers make, so traffic this host sends gets
   steered at the far end. The queue is the peer's to pick and the rules
   are the peer's to install, so this needs nothing from the local
   device and can be turned on where vc-steer-cap is absent.

Splitting them is what makes one sided deployment work. Turn granting on
everywhere, cheaply, and asking wherever the NIC can actually do it.

Split the feature patch also? In three parts, one to add generic
extension header support (and all zero VC), one that adds tx granting
and finally one that adds rx requests.