netdev - Re: Driver has suspect GRO implementation, TCP performance may be compromised.

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: <50261bc0-2732-5adb-1ff6-a4ac040e39b1@gmail.com>
Date:   Thu, 30 May 2019 16:56:15 -0700
From:   Eric Dumazet <eric.dumazet@...il.com>
To:     Alexander Duyck <alexander.duyck@...il.com>,
        Stephen Hemminger <stephen@...workplumber.org>
Cc:     Eric Dumazet <edumazet@...gle.com>,
        Paul Menzel <pmenzel@...gen.mpg.de>,
        Jeff Kirsher <jeffrey.t.kirsher@...el.com>,
        intel-wired-lan <intel-wired-lan@...ts.osuosl.org>,
        netdev <netdev@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: Driver has suspect GRO implementation, TCP performance may be
 compromised.



On 5/30/19 3:52 PM, Alexander Duyck wrote:

> Actually I think there are some parts that don't have any receive
> limits that are supported by the e1000 part. What ends up happening is
> that we only drop the packet if it spans more than one buffer if I
> recall correctly, and buffer size is determined by MTU.
> 
> I always thought MTU only applied to transmit since it is kind of in
> the name. As a result I am pretty sure igb and ixgbe will be able to
> trigger this warning under certain circumstances as well. Also what
> about the case where someone sets the MTU to less than 1500? I think
> most NICs probably don't update their limits in such a case and
> wouldn't it also trigger a similar error?
> 


Linux does not have a notion of MRU, mtu is used for both tx and rx.

Most NIC drivers allocate skb of the maximal size (derived from netdev->mtu)
and program the NIC to drop packets bigger than X bytes  (X also derived from netdev->mtu)

Another interesting point is that Paul host is receiving big packets,
that means that one host in his local network is overriding the 1500 MTU :)

Eventually we could add a netdev->mru and allow few drivers to set
their maximal mru, if bigger than netdev->mtu.

e1000e would probably set netdev->mru to 2048 - sizeof(ethernet headers), if
the driver is operating at MTU = 1500