Re: [PATCH v2] Receive Packet Steering

[Tom Herbert <therbert@google.com>]

>
> > Right.  In fact, just using the hash as the key is what you want when
> > device provides the hash (i.e. Toeplitz).  The caveat is that we
> > should to prevent OOO packets when threads migrate, I think I have a
> > reasonable solution for that following your earlier suggestion.
>
> But as you found, compared to jhash, Toeplitz is expensive to compute
> and you would need to do this if implemented by monitoring transmits.

Well I'd rather not have to compute any hash on transmit.  Toeplitz
could be populated in another field of skb from a saved value in the
socket struct.

>
> And furthermore, from the device perspective:
>
> 1) some (such as NIU) provide different hash values, not Toeplitz
>
> 2) it is expensive to extract this value (must enable different,
>   larger, RX descriptor modes, thus more DMA traffic, etc.)
>
> I really don't think Toeplitz is a net win, to be honest.

Using the Toeplitz hash in steering lookup has given us about 10% more
maximum pps (2 different NICs), and we haven't really noticed negative
effects because of the extra descriptor overhead-- so I'm not going to
give up on it too easily!  A device provided hash could probably be
used as an opaque value-- used as hash key into steering table on RX,
saved in socket structure in RX, and then sent with skb on transmit
during which it is used to update the steering table.  At the socket
layer, we would just need to collect and cache values in socket
structures.

>
> > I hope to have a new patch soon for steering packets to application
> > CPU and using device hash, thanks for bugging me on it!
>
> I had no choice, as I'm giving a presentation on this stuff tomorrow
> night here in NYC :-)

Cool, do you happen to have slides.... :-)