ECMP hash keys?

[Alexander V. Chernikov]

On 17.01.2014 02:08, Adrian Chadd wrote:
> The reason you need to make sure that you end up with hashes for both
> src,dst and dst,src being equivalent is to ensure that when you create
> an outbound socket, you know up front which path the receive path is
> going to come back on. Right now we don't mark new connections -
> inbound or outbound - with a flowid until we've received some data on
> it.
Well, this seems reasonable.

However, how do you plan to interact with hardware RSS?

For example, currently Intel used to set flowid to cpu number (which can
be reasonable in some cases). Afair 82599 advanced RX descriptor
contains original value that can be extracted, but we can't change cpu
on which packet arrives on (well, we can reprogram indirection table, but..)

I can't see any easy way to accomplish custom SW RSS:

We can possibly have 1-2-4 ingress HW queues per NIC, ignore driver
flowid, re-calculate with modified Toeplitz or similar and push to other
ncpu-1 neisr queues. That can work, but requires custom setup
(especially for lagg scenarios) and works well for small subset of
workloads.

It seems also guessing ingress flowid is not very much different between
symmetric and asymmetric hashing approaches.


> 
> It's also going to be eventually useful for the pcbgroup stuff, as
> vijay has said.
> 
> 
> -a
>