[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAEP_g=-y_-=r+BHk3VfzxMNwH=B-26DvQrzQ7gkKG8fDG7Mx3g@mail.gmail.com>
Date: Wed, 3 Dec 2014 16:54:36 -0800
From: Jesse Gross <jesse@...ira.com>
To: Thomas Graf <tgraf@...g.ch>
Cc: "Michael S. Tsirkin" <mst@...hat.com>,
"Du, Fan" <fan.du@...el.com>, Jason Wang <jasowang@...hat.com>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
"davem@...emloft.net" <davem@...emloft.net>,
"fw@...len.de" <fw@...len.de>,
"dev@...nvswitch.org" <dev@...nvswitch.org>,
Pravin Shelar <pshelar@...ira.com>
Subject: Re: [PATCH net] gso: do GSO for local skb with size bigger than MTU
On Wed, Dec 3, 2014 at 3:05 PM, Thomas Graf <tgraf@...g.ch> wrote:
> On 12/03/14 at 02:51pm, Jesse Gross wrote:
>> My proposal would be something like this:
>> * For L2, reduce the VM MTU to the lowest common denominator on the segment.
>> * For L3, use path MTU discovery or fragment inner packet (i.e.
>> normal routing behavior).
>> * As a last resort (such as if using an old version of virtio in the
>> guest), fragment the tunnel packet.
>
> That's what I had in mind as well although using a differentiator bit
> which indicates to the output path whether the packet is to be
> considered switched or routed and thus send ICMPs. The bit would be set
> per flow, thus allowing arbitary granularity of behaviour.
I don't think that we actually need a bit. I would expect that ICMP
generation to be coupled with routing (although this requires being
able to know what the ultimate MTU is at the time of routing the inner
packet). If that's the case, you just need to steer between L2 and L3
processing in the same way that you would today and ICMP would just
come in the right cases.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists