From: Cong Wang <amwang@redhat.com>
To: Jesse Gross <jesse@nicira.com>, Pravin Shelar <pshelar@nicira.com>
Cc: netdev@vger.kernel.org, Thomas Graf <tgraf@suug.ch>
Subject: A question on the design of OVS GRE tunnel
Date: Mon, 08 Jul 2013 17:51:05 +0800 [thread overview]
Message-ID: <1373277065.8227.26.camel@cr0> (raw)
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.
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.
Of course we can workaround this problem by:
1) lower down the MTU of the first net device to reserve some room for
GRE header
2) pass vnet_hdr=on to KVM guests so that packets going out there are
still GSO packets even on hosts (I never try this, just analysis it by
reading code)
Do we have to live with this? Can we solve this problem at OVS layer? So
that no matter how large the packets are we can avoid IP fragmentation?
One solution in my mind is registering a netdev for OVS GRE tunnel too,
so that we could probably reuse GRO cells, thus packets can be merged
before OVS processing them, and it will be segmented again before going
to the wire. But I could easily miss something here. ;)
What do you think? Any better idea to fix this?
Thanks!
next reply other threads:[~2013-07-08 9:51 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-07-08 9:51 Cong Wang [this message]
2013-07-08 16:28 ` A question on the design of OVS GRE tunnel Pravin Shelar
2013-07-09 2:41 ` Cong Wang
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=1373277065.8227.26.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).