On 4/9/15 10:56 AM, Tom Herbert wrote:
On Thu, Apr 9, 2015 at 10:46 AM, Erik Nordmark <[email protected]> wrote:
I thought the purpose of RFS was to send the packet (and associated
interrupt) to the CPU where the application process is running. That implies
an exact flow lookup. Some hash value, whether computed by the receiving NIC
or whether in some entropy field in the packet (computed by the sender or
encapsulator) would not suffice for that purpose.
RFS is technically a best effort mechanism where exact flow lookup is
not necessary, and in many cases the device won't even be able to
determine the actual transport like if the encapsulated packet was
encrypted. What we need for this to work is a very low probability of
collisions among active traffic, an occasional should be that a few
packets may be routed to the wrong CPU. It still works, but is
slightly suboptimal for those packets. There have been some related
issues reported on Linux netdev that 16-bits of indirection indexed by
hash value is not enough.
Of course, a hash value (e.g., from the entropy field) is useful for RSS.
Same value is used for RFS. NICs provide a 32 bit hash over 5-tuple.
Ah - I must have read the Linux description to quickly.
A hash works to spread the flows, and if the process is then scheduled
on the same CPU as where the packets arrive performance improves.
My point was that if you first one to schedule/bind the process to a CPU
and later ensure that the packets arrive on said CPU, then you need an
exact match and not a hash.
Thanks,
Erik
Tom
Regards,
Erik
_______________________________________________
nvo3 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/nvo3
_______________________________________________
nvo3 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/nvo3
