On Fri, Mar 18, 2016 at 4:24 PM, Alexander Duyck <adu...@mirantis.com> wrote: > In RFC 6864 it is stated that we can essentially ignore the IPv4 ID field > if we have not and will not use fragmentation. Such a frame is defined > as having the DF flag set to 1, and the MF and frag_offset as 0. Currently > for GRO we were requiring that the inner header always have an increasing > IPv4 ID, but we are ignoring the outer value. > > This patch is a first step in trying to reverse some of that. Specifically > what this patch does is allow us to coalesce frames that have a static IPv4 > ID value. So for example if we had a series of frames where the DF flag > was set we would allow the same IPv4 ID value to be used for all the frames > belonging to that flow. This would become the standard behavior for TCP so > it would support either a fixed IPv4 ID value, or one in which the value > increments. > > Signed-off-by: Alexander Duyck <adu...@mirantis.com>
One thing that is a bit odd is that the TSO output procedure stays the same. So that means that if we get a stream of packets with the DF bit set and a constant IP ID, aggregate them with GRO, and the retransmit with GSO/TSO then we'll get packets with IDs that increment for each burst and then start back again to the original value. I guess it doesn't matter in practice since the IDs are supposed to be ignored but it does seem a little strange - especially because the new packets will now be violating the rules of the same GRO implementation that produced them.
