netdev - Re: A question on the design of OVS GRE tunnel

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CALnjE+q4L9Q8Ebj+O-D8xQHyzSo=FZrb7A-XVEGERzeN-MZMGQ@mail.gmail.com>
Date:	Mon, 8 Jul 2013 09:28:00 -0700
From:	Pravin Shelar <pshelar@...ira.com>
To:	Cong Wang <amwang@...hat.com>
Cc:	Jesse Gross <jesse@...ira.com>, netdev@...r.kernel.org,
	Thomas Graf <tgraf@...g.ch>
Subject: Re: A question on the design of OVS GRE tunnel

On Mon, Jul 8, 2013 at 2:51 AM, Cong Wang <amwang@...hat.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.

> 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.

> 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!
>
--
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