On Wed, Apr 15, 2015 at 5:42 PM, Erik Nordmark <nordm...@acm.org> wrote: > On 4/9/15 10:56 AM, Tom Herbert wrote: >> >> On Thu, Apr 9, 2015 at 10:46 AM, Erik Nordmark <nordm...@acm.org> 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. > If the hash entropy is large enough to make collisions near zero, then the hash can be used a unique flow identifier. With a 32 bit hash value and say 10K active connections, there are very few collisions. The binding something like is Hash->Queue->CPU, so host can program which queue to receive packets on that match the hash.
In reality though, exact flow match is a fleeting concept in devices and the hash is really want we need anyway. We really don't want devices to need to parse every encapsulation protocol to find inner transport headers, and besides when we start encrypting encapsulated packets they won't be able to get to the exact flow anyway. Also, it's important that system can adapt to seeing flows whose outer hashes change (like when UDP source port changes). SPUD is also compelling here as a way to provide a specific more persistent and explicit flow identification which is needed for stateful inspection/firewalls for encapsulated transports. Tom > Thanks, > Erik > > >> >> Tom >> >>> Regards, >>> Erik >>> >>> _______________________________________________ >>> nvo3 mailing list >>> nvo3@ietf.org >>> https://www.ietf.org/mailman/listinfo/nvo3 > > _______________________________________________ nvo3 mailing list nvo3@ietf.org https://www.ietf.org/mailman/listinfo/nvo3
