On Tue, Feb 23, 2016 at 9:38 AM, Edward Cree <ec...@solarflare.com> wrote:
> 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".
Yes RFC6864.
>> 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.
Right, receive side is straightforward, just ignore IP IDs. Transmit
is more interesting. Operative code is in ip_select_ident_segs. The
comment as to why non-zero IDs are sent is:
/* This is only to work around buggy Windows95/2000
* VJ compression implementations. If the ID field
* does not change, they drop every other packet in
* a TCP stream using header compression.
*/
> --
> -Ed
