On Fri, 2016-04-01 at 11:05 -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. > > In addition we were generating IPv4 ID collisions when 2 or more flows were > interleaved over the same tunnel. To prevent that we store the result of > all IP ID checks via a "|=" instead of overwriting previous values.
Note that for atomic datagrams (DF = 1), since fragmentation and reassembly can not occur, maybe some people use ID field for other purposes. For example, TCP stack tracks per socket ID generation, even if it sends DF=1 frames. Damn useful for tcpdump analysis and drop inference. With your change, the resulting GRO packet would propagate the ID of first frag. Most GSO/GSO engines will then provide a ID sequence, which might not match original packets. I do not particularly care, but it is worth mentioning that GRO+TSO would not be idempotent anymore.
