On Sat, May 6, 2017 at 8:37 AM, lizho.jin <[email protected]> wrote: > I am not referring RSS, but RFS with HW acceleration. What I > > proposed is to use hash value instead of 5-tuple to do flow steering. > RFS works as is also. The only requirement for RFS is that the hash is reasonably consistent for a flow. The host should never need to reverse engineer the hash a NIC does.
Tom > Sorry for the misunderstanding. > > > Regards > Lizhong > > On 05/6/2017 23:24，Tom Herbert<[email protected]> wrote： > > On Fri, May 5, 2017 at 6:39 PM, lizho.jin <[email protected]> wrote: >> Tom, thanks for the reply, see inline below. >> >> Regards >> Lizhong >> >> On 05/6/2017 00:14，Tom Herbert<[email protected]> wrote： >> >> [Lizhong] Total option length will not solve the parser buffer issue. >> The parser buffer is located before parser, and for Geneve, implement >> 512Byte is the only way since the longest of Geneve header is >> 260Bytes. At least in some implementations as I know, hardware will >> firstly receive enough 512Bytes per packets, and send the 512Bytes to >> parser. Then parse will be able to skip over options to get inner >> payload. Did I have any misunderstanding? >> >> [Tom] Skipping header is useful so that transit devices can find the >> inner headers. The fact that there is no way to skip over an IPv6 >> extension header chain to find the transport headers of a packet has >> been a source of unhappiness. >> >> >> [Lizhong] That's correct, and if we have not any working around way, >> >> some device may fail to get inner header, just like IPv6 with too many >> >> extension headers fails to parse transport header. Currently many chips >> >> have this IPv6 extension header limitation. >> >> >> [Tom] The parser buffer limit applies to all headers a device wishes >> to inspect (some devices still may have less than 512 byte buffers >> also). The best way to deal with this is to minimize the length of >> headers. Geneve TLVs each have four bytes of overhead so they are less >> compact that other TLVs at similar layer (IP options, TCP options, >> IPv6 options each have two bytes overhead). The tradeoff made here is >> probably to simply alignment (I really don't see any rationale for >> needing 24 bits to identify options). Bit-fields are still better in >> this regard for being compact since there is no additional overhead >> per each option. >> >> >> [Lizhong] I suspect, a 260Bytes long Geneve header is an overload design. >> >> Since one of the purpose of NIC to parse inner header is to get a hash >> value >> >> to do flow steering, one way is to define a Geneve TLV which SHOULD be >> >> at the first one to carry the hash value of inner 5-tuple, and also hash >> algorithm. >> >> Then NIC may only need to parse to the first Geneve TLV. >> >> Note that the source UDP port could not serve that purpose since that port >> >> number could not be able to be predicted by the receiver. >> > Using the entropy in the UDP port number works perfectly well to get > ECMP or RSS for any UDP encapsulation including Geneve, VXLAN, GUE, > etc. If the UDP port number weren't good enough then the IPv6 flow > label can be used (and that works for _any_ protocol not just UDP!). > > > The goal should be to discourage intermediate devices from doing DPI > into transport layer payloads. It requires a bunch of protocol > specific logic and any interpretation may be completely wrong since > port numbers don't have global meaning (e.g. if a device see a UDP > port destined to port 6081 in the network it may or may not be > Geneve). > > Tom > >> >> >> _______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
