Tom, thanks for the reply, see inline below.
Regards
Lizhong
On 05/6/2017 00:14，Tom Herbert<t...@herbertland.com> 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.
_______________________________________________ nvo3 mailing list nvo3@ietf.org https://www.ietf.org/mailman/listinfo/nvo3
