netdev
[Top] [All Lists]

Re: [RFC/PATCH] "strict" ipv4 reassembly

To: "David S. Miller" <davem@xxxxxxxxxxxxx>
Subject: Re: [RFC/PATCH] "strict" ipv4 reassembly
From: Andi Kleen <ak@xxxxxx>
Date: Tue, 17 May 2005 20:38:25 +0200
Cc: netdev@xxxxxxxxxxx, akepner@xxxxxxx
In-reply-to: <20050517.104947.112621738.davem@davemloft.net> (David S. Miller's message of "Tue, 17 May 2005 10:49:47 -0700 (PDT)")
References: <Pine.LNX.4.61.0505170914130.29021@linux.site> <20050517.104947.112621738.davem@davemloft.net>
Sender: netdev-bounce@xxxxxxxxxxx
User-agent: Gnus/5.110002 (No Gnus v0.2) Emacs/21.3 (gnu/linux)
"David S. Miller" <davem@xxxxxxxxxxxxx> writes:

> From: Arthur Kepner <akepner@xxxxxxx>
> Date: Tue, 17 May 2005 09:18:26 -0700 (PDT)
>
>>   1) Fragments must arrive in order (or in reverse order) -
>>      out of order fragments are dropped. 
>
> Even the most simplistic flow over the real internet
> can get slight packet reordering.
>
> Heck, reordering happens on SMP on any network.
>
> IP is supposed to be resilient to side effects of network
> topology, and one such common side effect is packet reordering.
> It's common, it's fine, and the networking stack deals with it
> gracefully.  Strict reassembly does not.

If anything it would be better as a per route flag.
Then you could set it only for your local network
where you know Gigabit happens and reordering might
be avoidable in some cases.

-Andi

P.S.: Arthur I think your arguments would have more
force if you published the test program that demonstrates the
corruption.


<Prev in Thread] Current Thread [Next in Thread>