From: Edward Cree <ec...@solarflare.com> Date: Tue, 23 Feb 2016 17:38:28 +0000
> On 23/02/16 17:20, Rick Jones wrote: >> On 02/23/2016 08:47 AM, Tom Herbert wrote: >>> Right, GRO should probably not coalesce packets with non-zero IP >>> identifiers due to the loss of information. Besides that, RFC6848 says >>> the IP identifier should only be set for fragmentation anyway so there >>> shouldn't be any issue and really no need for HW TSO (or LRO) to >>> support that. >> >> You sure that is RFC 6848 "Specifying Civic Address Extensions in the >> Presence Information Data Format Location Object (PIDF-LO)" ? > PossiblyRFC 6864 "Updated Specification of the IPv4 ID Field". >> In whichever RFC that may be, is it a SHOULD or a MUST, and just how many >> "other" stacks might be setting a non-zero IP ID on fragments with DF set? > "The IPv4 ID field MUST NOT be used for purposes other than fragmentation > and reassembly."(§4.1) > "Originating sources MAY set the IPv4 ID field of atomic datagrams to any > value."(§4.1) > "All devices that examine IPv4 headers MUST ignore the IPv4 ID field of > atomic datagrams."(§4.1) > Atomic datagrams are defined by "(DF==1)&&(MF==0)&&(frag_offset==0)" (§4). > > So it's OK to coalesce packets with different identifiers, as long as they > have DFset (and aren't fragmented already). Also, the RFC takes pains to > point out that it "does not reserve any IPv4 ID values, including 0, as > distinguished" (§4.1), so one cannot rely on the ID always being zero. Just a reminder that a very long time ago we tried setting the IP ID field to zero for DF packets, and this broke SLHC because that expects a monotonically increasing IP ID field.
