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
| ||
|
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
Powered by blists - more mailing lists