netdev - Re: [PATCH net] gso: do GSO for local skb with size bigger than MTU

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: <20141130151114.GA4462@breakpoint.cc>
Date:	Sun, 30 Nov 2014 16:11:14 +0100
From:	Florian Westphal <fw@...len.de>
To:	"Du, Fan" <fan.du@...el.com>
Cc:	Florian Westphal <fw@...len.de>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	"davem@...emloft.net" <davem@...emloft.net>
Subject: Re: [PATCH net] gso: do GSO for local skb with size bigger than MTU

Du, Fan <fan.du@...el.com> wrote:
> All interface MTU in the test scenario is the default one, 1500.

Not really, unless I misunderstand the setup.

You have a l2 network where part of the machines are connected by a
l2 tunnel.

All machines within that network ought to assume that MTU is equal for
all machines within the same L2 network.

> >It seems to me to only clean solution is to set tap0 MTU so that it accounts for the
> >bridge encap overhead.
> 
> This will force _ALL_ deploy instances requiring tap0 MTU change in every cloud env.

Yes, alternatively emply routing, then PMTU should work.

> Current behavior leads over-mtu-sized packet push down to NIC, which should not
> happen anyway. And as I putted in another threads:
> Perform GSO for skb, then try to do ip segmentation if possible, If DF set, send back
> ICMP message. If DF is not set, apparently user want stack do ip segmentation, and
> All the GSO-ed skb will be sent out correctly as expected.

Well, the linux bridge implementation (especially bridge netfilter)
did/allows for a lot of layering violations and this has usually caused
a myriad of followup kludges to make one-more scenario work.

I still think that trying to make this work is a bad idea.
If hosts have different MTUs they should be in different l2 networks.

Alternatively, the Tunneling implementation should be opaque and do the
needed fragmentation to provide the illusion of identical MTUs.

That said, I don't see anything wrong with the patch per se, I just
dislike the concept.
--
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