[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <1461381070.97911800.1478267353507.JavaMail.zimbra@redhat.com>
Date: Fri, 4 Nov 2016 09:49:13 -0400 (EDT)
From: Lance Richardson <lrichard@...hat.com>
To: Shmulik Ladkani <shmulik.ladkani@...il.com>
Cc: Hannes Frederic Sowa <hannes@...essinduktion.org>, fw@...len.de,
netdev@...r.kernel.org, jtluka@...hat.com
Subject: Re: [PATCH net v3] ipv4: allow local fragmentation in
ip_finish_output_gso()
> From: "Shmulik Ladkani" <shmulik.ladkani@...il.com>
> To: "Hannes Frederic Sowa" <hannes@...essinduktion.org>
> Cc: "Lance Richardson" <lrichard@...hat.com>, fw@...len.de, netdev@...r.kernel.org, jtluka@...hat.com
> Sent: Friday, November 4, 2016 5:40:14 AM
> Subject: Re: [PATCH net v3] ipv4: allow local fragmentation in ip_finish_output_gso()
>
> On Thu, 3 Nov 2016 22:34:34 +0100 Hannes Frederic Sowa
> <hannes@...essinduktion.org> wrote:
> > Correct, but we should maybe redefine the code a bit. From my
> > understanding we can now create an ICMP storm in case every fragment gets.
>
> Yes, you are right.
>
> Each segment gets into ip_fragment, and due to outer DF being set,
> ICMP_FRAG_NEEDED is sent per segment.
>
> BTW, suppose GRO is off, and sender actually did send a burst of
> (non-gso) packets with outer DF set, and each was tunnel encapsulated,
> resulting in oversized frames.
>
> Would'nt the stack just send the ICMP_FRAG_NEEDED per encapsulated
> frame?
>
> If so, then the GRO behaviour is aligned, and there's nothing to fix.
>
Agree.
> Best,
> Shmulik
>
Powered by blists - more mailing lists