On Mon, Apr 04, 2016 at 09:31:21AM -0700, Alexander Duyck wrote: > RFC 6864 states that the IPv4 ID field MUST NOT be used for purposes other > than fragmentation and reassembly. Currently we are looking at this field > as a way of identifying what frames can be aggregated and which cannot for > GRO. While this is valid for frames that do not have DF set, it is invalid > to do so if the bit is set.
This justification is bogus. GRO is a completely local optimisation that should have zero visibility to third parties. So it makes no sense to talk about RFC compliance of GRO. The Linux network stack as a whole is subject to RFC compliance, but not GRO per se. > In the case of the non-incrementing IP ID we will end up losing the data > that the IP ID is fixed. However as per RFC 6864 we should be able to > write any value into the IP ID when the DF bit is set so this should cause > minimal harm. No we should not do that, at least not by default. GRO was designed to be completely lossless, that is its main advantage of the various forms of LRO which preceded it. If you lose that people will start asking it to be disabled for routers/bridges and we'll be back in the same old mess that we had with LRO. So please do this properly and preserve the information in the packet. As I said earlier all it takes is one single bit, like we do with ECN. If you put it in the feature bit you'll also allow us to distinguish between TSO drivers that produce fixed IDs vs. incrementing IDs. Cheers, -- Email: Herbert Xu <herb...@gondor.apana.org.au> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
