On Thu, Apr 9, 2015 at 10:46 AM, Erik Nordmark <[email protected]> wrote: > On 4/8/15 8:11 PM, Lizhong Jin wrote: >> >> [Lizhong] If the NVE and tenant is integrated into one device, then the >> issue could >> be solved by implementation. Because tenant know the entropy value of the >> first >> segment, and use the same value to the subsequent segment. So different >> implementation model could provide different entropy value. Or do we need >> other >> mechanism to mitigate this issue, e.g., fragment on NVE in >> draft-herbert-gue-fragmentation. > > Lizhong, > > My point was more fundamental. Today on the Internet there are routers which > do hashing for LAG or ECMP purposes. They have the same issues with > fragmented packets. >> >> >>>> For section 18.1.1, I suggest RFS should be analyzed. E.g., if NIC >>>> want to do flow steering based on the inner header information, then >>>> it could use entropy value instead of the inner header information. >>> >>> Did you mean Receive Side Scaling (RSS)? That is mentioned in the >>> document - >>> section 18.1.1 . Perhaps the RSS text can be improved. >>> Receive Flow Scaling is the name of a Linux software technique to take >>> into >>> account the CPU on which the application is running, which is different. >> >> [Lizhong] I am referring to hardware based flow steering, similar with >> Accelerated >> RFS (Receive Flow Steering). In the NIC I/O virtualization, the NIC will >> directly trigger >> interrupt to the CPU where application is running by looking up a flow >> table. We will >> use the inner header to do the flow table lookup, if hardware could not >> parse the >> inner header, then entropy value in the encapsulation is required. Any >> design of >> hiding inner header information should consider above implementation. >> > > 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. 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
