linux-kernel - Re: [PATCH net] vmxnet3: use gro callback when UPT is enabled

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: <1743CDA0-8F35-4F60-9D22-A17788B90F9B@vmware.com>
Date:   Thu, 16 Mar 2023 04:03:52 +0000
From:   Ronak Doshi <doshir@...are.com>
To:     Yunsheng Lin <linyunsheng@...wei.com>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>
CC:     "stable@...r.kernel.org" <stable@...r.kernel.org>,
        Pv-drivers <Pv-drivers@...are.com>,
        "David S. Miller" <davem@...emloft.net>,
        Eric Dumazet <edumazet@...gle.com>,
        Jakub Kicinski <kuba@...nel.org>,
        Paolo Abeni <pabeni@...hat.com>,
        Guolin Yang <gyang@...are.com>,
        open list <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH net] vmxnet3: use gro callback when UPT is enabled


> On 3/15/23, 6:47 PM, "Yunsheng Lin" <linyunsheng@...wei.com <mailto:linyunsheng@...wei.com>> wrote:
>
> That's the piont I am trying to make.
> If I understand it correctly, you can not change callback from napi_gro_receive() to
> netif_receive_skb() when netdev->features has the NETIF_F_GRO bit set.
Where are we doing this? Our preference is to use netif_receive_skb() only when LRO is enabled.
If both LRO and GRO are enabled on the vnic, which API should be used?

> NETIF_F_GRO bit in netdev->features is to tell user that netstack will perform the
> software GRO processing if the packet can be GRO'ed.
Even if the packet is already LRO'ed?

> Calling netif_receive_skb() with NETIF_F_GRO bit set in netdev->features will cause
> confusion for user, IMHO.
As long as LRO is enabled and performed by ESXi (which it will do), I don’t think user cares for GRO.
Even if we use napi_gro_receive() for such case, it degrades the performance as unnecessary cycles
are spend on an already LRO'ed packet.


> As above, there is different feature bit for that, NETIF_F_LRO, NETIF_F_GRO and
> NETIF_F_GRO_HW.
> IMHO, deciding which callback to be used depending on some driver configuation
> without corporation with the above feature bits does not seems right to me.

We are not neglecting feature bits. We just know that in UPT LRO won’t be done, so we by
default use napi_gro_receive() callback.

Thanks, 
Ronak