Hi, >From this discussion, at least I could see the hardware flow steering need to >be considered in following aspects: 1. 32bit hash value will benefit the loadbalancing of CPU load when flow steering is applied. If two flows has collision to have hash value, then RFS on CPU will steer the flow to dst CPU. But that will burden the CPU load if there are too many collisions. 2. I still suggest to describe some suggestions for the hash function of the entropy value. The hash function should provide collision rate as lower as possible. Then the NIC could decide whether trust the received entropy value to do flow steering. If not trust, then revert to RSS.
BR Lizhong > -----Original Message----- > From: Tom Herbert [mailto:[email protected]] > Sent: 2015年4月17日 6:04 > To: Erik Nordmark > Cc: Lizhong Jin; [email protected] > Subject: Re: [nvo3] Encapsulation considerations > > On Wed, Apr 15, 2015 at 5:42 PM, Erik Nordmark <[email protected]> wrote: > > 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. > > > 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 > >>> [email protected] > >>> https://www.ietf.org/mailman/listinfo/nvo3 > > > > _______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
