netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: David Miller <davem@davemloft.net>
To: fan.du@intel.com
Cc: netdev@vger.kernel.org, fw@strlen.de
Subject: Re: [PATCH net] gso: do GSO for local skb with size bigger than MTU
Date: Tue, 02 Dec 2014 19:23:11 -0800 (PST)	[thread overview]
Message-ID: <20141202.192311.1226452173523245977.davem@davemloft.net> (raw)
In-Reply-To: <1417156385-18276-1-git-send-email-fan.du@intel.com>

From: Fan Du <fan.du@intel.com>
Date: Fri, 28 Nov 2014 14:33:05 +0800

> Test scenario: two KVM guests sitting in different
> hosts communicate to each other with a vxlan tunnel.
> 
> All interface MTU is default 1500 Bytes, from guest point
> of view, its skb gso_size could be as bigger as 1448Bytes,
> however after guest skb goes through vxlan encapuslation,
> individual segments length of a gso packet could exceed
> physical NIC MTU 1500, which will be lost at recevier side.
> 
> So it's possible in virtualized environment, locally created
> skb len after encapslation could be bigger than underlayer
> MTU. In such case, it's reasonable to do GSO first,
> then fragment any packet bigger than MTU as possible.
> 
> +---------------+ TX     RX +---------------+
> |   KVM Guest   | -> ... -> |   KVM Guest   |
> +-+-----------+-+           +-+-----------+-+
>   |Qemu/VirtIO|               |Qemu/VirtIO|
>   +-----------+               +-----------+
>        |                            |
>        v tap0                  tap0 v
>   +-----------+               +-----------+
>   | ovs bridge|               | ovs bridge|
>   +-----------+               +-----------+
>        | vxlan                vxlan |
>        v                            v
>   +-----------+               +-----------+
>   |    NIC    |    <------>   |    NIC    |
>   +-----------+               +-----------+
> 
> Steps to reproduce:
>  1. Using kernel builtin openvswitch module to setup ovs bridge.
>  2. Runing iperf without -M, communication will stuck.
> 
> Signed-off-by: Fan Du <fan.du@intel.com>

I really don't like this at all.

If guest sees a 1500 byte MTU, that's it's link layer MTU and it had
better be able to send 1500 byte packets onto the "wire".

If you cannot properly propagate the vxlan encapsulation overhead back
into the guest's MTU you must hide this problem from the rest of our
stack somehow.

Nothing we create inside the host should need the change that you
are making.

  parent reply	other threads:[~2014-12-03  3:18 UTC|newest]

Thread overview: 57+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-11-28  6:33 [PATCH net] gso: do GSO for local skb with size bigger than MTU Fan Du
2014-11-28  7:02 ` Jason Wang
2014-11-30 10:08   ` Du, Fan
2014-12-01 13:52     ` Thomas Graf
     [not found]       ` <20141201135225.GA16814-FZi0V3Vbi30CUdFEqe4BF2D2FQJk+8+b@public.gmane.org>
2014-12-01 15:06         ` Michael S. Tsirkin
2014-12-02 15:48         ` Flavio Leitner
2014-12-02 17:09           ` Thomas Graf
     [not found]             ` <20141202170927.GA9457-FZi0V3Vbi30CUdFEqe4BF2D2FQJk+8+b@public.gmane.org>
2014-12-02 17:34               ` Michael S. Tsirkin
2014-12-02 17:41                 ` Thomas Graf
2014-12-02 18:12                   ` Jesse Gross
     [not found]                     ` <CAEP_g=-86Z6pxNow-wjnbx_v9er_TSn6x5waigqVqYHa7tEQJw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2014-12-03  9:03                       ` Michael S. Tsirkin
2014-12-03 18:07                         ` Jesse Gross
     [not found]                           ` <CAEP_g=9C+D3gbjJ4n1t6xuyjqEAMYi4ZfqPoe92UAoQJH-UsKg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2014-12-03 18:38                             ` Michael S. Tsirkin
2014-12-03 18:56                               ` Rick Jones
     [not found]                                 ` <547F5CC2.8000908-VXdhtT5mjnY@public.gmane.org>
2014-12-04 10:17                                   ` Michael S. Tsirkin
2014-12-03 19:38                               ` Jesse Gross
2014-12-03 22:02                                 ` Thomas Graf
     [not found]                                   ` <20141203220244.GA8822-FZi0V3Vbi30CUdFEqe4BF2D2FQJk+8+b@public.gmane.org>
2014-12-03 22:50                                     ` Michael S. Tsirkin
2014-12-03 22:51                                   ` Jesse Gross
2014-12-03 23:05                                     ` Thomas Graf
     [not found]                                       ` <20141203230551.GC8822-FZi0V3Vbi30CUdFEqe4BF2D2FQJk+8+b@public.gmane.org>
2014-12-04  0:54                                         ` Jesse Gross
2014-12-04  1:15                                           ` Thomas Graf
2014-12-04  1:51                                             ` Jesse Gross
2014-12-04  9:26                                               ` Thomas Graf
2014-12-04 23:19                                                 ` Jesse Gross
2014-12-04  7:48                                     ` Du Fan
2014-12-04 23:23                                       ` Jesse Gross
2014-12-05  0:25                                         ` Du Fan
2014-12-03  2:31                   ` Du, Fan
2015-01-05  6:02                     ` Fan Du
     [not found]                       ` <54AA2912.6090903-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2015-01-05 17:58                         ` Jesse Gross
2015-01-06  9:34                           ` Fan Du
2015-01-06 19:11                             ` Jesse Gross
     [not found]                               ` <CAEP_g=8bCR=PeSoi09jLWLtNUrxhzx45h1Wm=9D=R57AqUac2w-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2015-01-07  5:58                                 ` Fan Du
2015-01-07 20:52                                   ` Jesse Gross
     [not found]                                     ` <CAEP_g=8EBeQUFkRRsG3sznYryd+LE9qJKWQXfS==HG2HDO=UKA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2015-01-08  9:39                                       ` Fan Du
2015-01-08 19:55                                         ` Jesse Gross
     [not found]                                           ` <CAEP_g=9hh+MG7AWEnct7CwRqp=ZghpbkDeQ5BhGQktDgMST1jA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2015-01-09  5:42                                             ` Fan Du
2015-01-12 18:48                                               ` Jesse Gross
2015-01-09  5:48                                           ` Fan Du
2015-01-12 18:55                                             ` Jesse Gross
2015-01-13 16:58                                               ` Thomas Graf
2014-12-02 15:44     ` Flavio Leitner
2014-12-02 18:06       ` Jesse Gross
2014-12-02 21:32         ` Flavio Leitner
2014-12-02 21:47           ` Jesse Gross
2014-12-03  1:58           ` Du, Fan
2014-11-30 10:26 ` Florian Westphal
2014-11-30 10:55   ` Du, Fan
2014-11-30 15:11     ` Florian Westphal
2014-12-01  6:47       ` Du, Fan
2014-12-03  3:23 ` David Miller [this message]
2014-12-03  3:32   ` Du, Fan
2014-12-03  4:35     ` David Miller
2014-12-03  4:50       ` Du, Fan
2014-12-03  5:14         ` David Miller
2014-12-03  6:53           ` Du, Fan

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20141202.192311.1226452173523245977.davem@davemloft.net \
    --to=davem@davemloft.net \
    --cc=fan.du@intel.com \
    --cc=fw@strlen.de \
    --cc=netdev@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).