netdev - Re: [PATCHv3 net-next 2/3] sunvnet: allow admin to set sunvnet 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] [day] [month] [year] [list]

Date:	Sun, 14 Sep 2014 09:24:16 -0400
From:	David L Stevens <david.stevens@...cle.com>
To:	sowmini.varadhan@...cle.com, David Miller <davem@...emloft.net>
CC:	netdev@...r.kernel.org
Subject: Re: [PATCHv3 net-next 2/3] sunvnet: allow admin to set sunvnet MTU

On 09/14/2014 08:21 AM, Sowmini Varadhan wrote:

> To put things in perspective, in practice its only legacy linux today that will do the v1.0, and administrators are likely to want to upgrade
> to the later version, so encumbering the code with legacy version support may end up becoming hard-to-maintain code?

No, v1.8 Solaris would force us to a 1/3 drop in performance between linux LDOMs because of its 16000 byte MTU limit.
I don't think it's particularly hard to maintain -- it's virtually a literal translation of the text in the VIO protocol
document. Everything that's there should stay there; only new revisions of the protocol would cause new changes, presumably
in other areas of the code where those new features are implemented. And I don't think reverse compatibility is optional.

> As I understand it, this method of sending ICMP from the driver will not
> work for L2 (non-IP) packets, and it will not even work for IP packets that are coming to us, from, say, openvswitch, right? So in practice it
> actually has limited usability?

It wouldn't work for a bridged L2 network with no local IP address, because there would be no valid return IP address for the
ICMP error we generate (in IPv4 -- IPv6 will always have a valid link-local address). Everything else, including openvswitch as far
as I can tell, should make use of the standard pmtud routing information that these update.

What I come back to, as before, is the simple notion that nothing forces an administrator to the otherwise unusual circumstance
of setting different MTUs on directly-attached common networks. If you want to bridge L2 traffic, make your MTU 1500 and it'll
work exactly as before. If you, instead, are using IPv4 or IPv6 and ordinary routed traffic, you can have 8X performance improvement
between hosts that can support it, even if other hosts on the same vswitch and outside your control cannot. You can talk to all
hosts on the vswitch, with a performance that matches the capabilities of each peer. I don't see any way that's not better.

									+-DLS
--
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