netdev - Re: [PATCH net 1/2] net: dsa: be compatible with DSA masters with max

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]

Message-ID: <20200421145059.GC933345@lunn.ch>
Date:   Tue, 21 Apr 2020 16:50:59 +0200
From:   Andrew Lunn <andrew@...n.ch>
To:     Vladimir Oltean <olteanv@...il.com>
Cc:     Florian Fainelli <f.fainelli@...il.com>,
        Vivien Didelot <vivien.didelot@...il.com>,
        "David S. Miller" <davem@...emloft.net>,
        Oleksij Rempel <o.rempel@...gutronix.de>,
        netdev <netdev@...r.kernel.org>
Subject: Re: [PATCH net 1/2] net: dsa: be compatible with DSA masters with
 max_mtu of 1500 or less

> > We have always assumed the slave can send normal sized frames,
> > independent of what the master supports. This is just a follow on from
> > the fact we ignore errors setting the MTU on the master for the DSA
> > overhead for normal size frames. So don't set the MTU to 1496, leave
> > it at 1500. For all working boards out in the wild, 1500 will work.
> >
> >          Andrew
> 
> Does iperf3 TCP work on your Vybrid board with the master MTU equal to
> the slave MTU equal to 1500 (without IP fragmentation, that is)? If it
> does, ok, this patch can maybe be dropped.

Yes it does.

> qca7000 doesn't support packets larger than 1500 MTU either, neither
> does broadcom b44, and neither do probably more adapters which I
> didn't find now.

And unfortunately, there are probably a similar number of devices
which do work, and don't have correct MTU settings. So long as the IP
stack does MTU correctly, it does not matter what the network device
does with frames bigger than the MTU. And so network devices whos MTU
handling is wrong never causes issues, and so never get detected and
fixed.

We have to live in a world where trying to be correct is going to
cause regressions because of poor decisions in the past. But we can do
jumbo correctly, since it is new, it cannot regress. And doing jumbo
correct will help find some of these network drivers which do MTU
settings wrong.

      Andrew