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.