From: Cong Wang <amwang@redhat.com>
To: Pravin Shelar <pshelar@nicira.com>
Cc: Jesse Gross <jesse@nicira.com>,
netdev@vger.kernel.org, Thomas Graf <tgraf@suug.ch>
Subject: Re: A question on the design of OVS GRE tunnel
Date: Tue, 09 Jul 2013 10:41:06 +0800 [thread overview]
Message-ID: <1373337666.4557.13.camel@cr0> (raw)
In-Reply-To: <CALnjE+q4L9Q8Ebj+O-D8xQHyzSo=FZrb7A-XVEGERzeN-MZMGQ@mail.gmail.com>
On Mon, 2013-07-08 at 09:28 -0700, Pravin Shelar wrote:
> On Mon, Jul 8, 2013 at 2:51 AM, Cong Wang <amwang@redhat.com> wrote:
> > Hi, Jesse, Pravin
> >
> > I have a question on the design of OVS GRE tunnel. Why OVS GRE tunnel
> > doesn't register a netdev? I understand it is enough for GRE to function
> > without registering a netdev, just a GRE vport is sufficient and
> > probably even simpler.
> >
> kernel-gre device has gre-parameters/state associated with it and
> ovs-gre-vport is completely stateless. ovs-gre state is in user-space
> which make kernel module alot simpler. Therefore I doubt it will be
> easy or simpler to use netdev at this point.
Understood, from users' point of view, it is simpler. At least no one is
able to assign any IP address to it.
>
> > However, I noticed there is some problem with such design:
> >
> > I saw very bad performance with the _default_ setup with OVS GRE. After
> > digging it a little bit, clearly the cause is that OVS GRE tunnel adds
> > an outer IP header and a GRE header for every packet that passed to it,
> > which could result in a packet whose length is larger than the MTU of
> > the uplink, therefore after the packet goes through OVS, it has to be
> > fragmented by IP before going to the wire.
> >
> I do not understand what do you mean, gre packets greater than MTU
> must be fragmented before sent on wire and it is done by GRE-GSO code.
>
Well, I said fragment, not segment. This is exactly why performance is
so bad.
In my _default_ setup, every net device on the path has MTU=1500,
therefore, the packets coming out of a KVM guest can have length=1500,
after they go through OVS GRE tunnel, their length becomes 1538 because
of the added GRE header and IP header.
After that, since the packets are not GSO (unless you pass vnet_hdr=on
to KVM guest), the packets with length=1538 will be _fragmented_ by IP
layer, since the dest uplink has MTU=1500 too. This is why I proposed to
reuse GRO cell to merge the packets, which requires a netdev...
This is the problem.
next prev parent reply other threads:[~2013-07-09 2:41 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-07-08 9:51 A question on the design of OVS GRE tunnel Cong Wang
2013-07-08 16:28 ` Pravin Shelar
2013-07-09 2:41 ` Cong Wang [this message]
2013-07-09 6:26 ` Jesse Gross
2013-07-10 3:34 ` Cong Wang
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=1373337666.4557.13.camel@cr0 \
--to=amwang@redhat.com \
--cc=jesse@nicira.com \
--cc=netdev@vger.kernel.org \
--cc=pshelar@nicira.com \
--cc=tgraf@suug.ch \
/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).