| 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
| ||
|
Message-ID: <20130501094645.715bb462@vostro> Date: Wed, 1 May 2013 09:46:45 +0300 From: Timo Teras <timo.teras@....fi> To: David Miller <davem@...emloft.net> Cc: netdev@...r.kernel.org Subject: Re: [regression] [analyzed] fragmentation broken for tunnel devices On Wed, 20 Mar 2013 13:46:40 -0400 (EDT) David Miller <davem@...emloft.net> wrote: > From: Timo Teras <timo.teras@....fi> > Date: Wed, 20 Mar 2013 10:13:18 +0200 > > Thanks for investigating this issue. > > > 3) Reimplement fragmentation in tunnel devices. This means some > > duplication of code. But now that there's GRO support in tunnels, > > this would seem the most performant option. > > I think this is the best option, especially in the long term. I've been thinking more. It seems there's going to be tricky cases with this approach too. Looks like ICMP and other non-TCP/UDP packets are not really sent as GSO/GRO packets. So for those we end up fragmenting multiple times and end up sending double the amount of packets than needed. This would also mean that if we are ever to support new protocols, e.g. MPLS, we'd get a whole new can of forms when needing fragmentation. I'm wondering now if it'd be easier to just do the additional nexthop consultation for forward routes where destination is a tunnel device. - Timo -- 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