>-----Original Message----- >From: Thomas Graf [mailto:t...@infradead.org] On Behalf Of Thomas Graf >Sent: Wednesday, December 3, 2014 1:42 AM >To: Michael S. Tsirkin >Cc: Du, Fan; 'Jason Wang'; net...@vger.kernel.org; da...@davemloft.net; >f...@strlen.de; dev@openvswitch.org; je...@nicira.com; pshe...@nicira.com >Subject: Re: [PATCH net] gso: do GSO for local skb with size bigger than MTU > >On 12/02/14 at 07:34pm, Michael S. Tsirkin wrote: >> On Tue, Dec 02, 2014 at 05:09:27PM +0000, Thomas Graf wrote: >> > On 12/02/14 at 01:48pm, Flavio Leitner wrote: >> > > What about containers or any other virtualization environment that >> > > doesn't use Virtio? >> > >> > The host can dictate the MTU in that case for both veth or OVS >> > internal which would be primary container plumbing techniques. >> >> It typically can't do this easily for VMs with emulated devices: >> real ethernet uses a fixed MTU. >> >> IMHO it's confusing to suggest MTU as a fix for this bug, it's an >> unrelated optimization. >> ICMP_DEST_UNREACH/ICMP_FRAG_NEEDED is the right fix here. > >PMTU discovery only resolves the issue if an actual IP stack is running inside >the >VM. This may not be the case at all. ^^^^^^^^^^^^^^^^^^^^^^^^^^^
Some thoughts here: Think otherwise, this is indeed what host stack should forge a ICMP_DEST_UNREACH/ICMP_FRAG_NEEDED message with _inner_ skb network and transport header, do whatever type of encapsulation, and thereafter push such packet upward to Guest/Container, which make them feel, the intermediate node or the peer send such message. PMTU should be expected to work correct. And such behavior should be shared by all other encapsulation tech if they are also suffered. >I agree that exposing an MTU towards the guest is not applicable in all >situations, >in particular because it is difficult to decide what MTU to expose. It is a >relatively >elegant solution in a lot of virtualization host cases hooked up to an >orchestration >system though. _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
