netdev - Re: [PATCH net-next 4/4] qede: Use NETIF_F_GRO

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]

Date:   Tue, 5 Dec 2017 09:13:53 -0800
From:   Michael Chan <michael.chan@...adcom.com>
To:     "Chopra, Manish" <Manish.Chopra@...ium.com>
Cc:     Yuval Mintz <yuvalm@...lanox.com>,
        "davem@...emloft.net" <davem@...emloft.net>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "Elior, Ariel" <Ariel.Elior@...ium.com>,
        Dept-Eng Everest Linux L2 <Dept-EngEverestLinuxL2@...ium.com>
Subject: Re: [PATCH net-next 4/4] qede: Use NETIF_F_GRO_HW.

On Tue, Dec 5, 2017 at 4:32 AM, Chopra, Manish <Manish.Chopra@...ium.com> wrote:

>
> Since we are now differentiating HW gro with distinct feature bit, I think we should consider this feature bit everywhere where driver disables
> HW gro internally [not explicitly using ethtool]. This is not just specific to XDP but on some other conditions also driver disables HW gro in load flow.
> I think with just this change we would end up with showing HW gro feature enabled but actually driver has disabled it in XDP or other scenarios internally.
>
> I don't know if it's a good thing to do but just a suggestion -
> What if in driver load flow that is in the end of function qede_alloc_mem_rxq() we do something like below so that it will actually represent
> the actual state of the feature ?
>
> If (edev->gro_disable) {
>         ndev->hw_features &= ~ NETIF_F_GRO_HW;
>         ndev->features &= ~ NETIF_F_GRO_HW;
> }

If edev->gro_disable means that the current configuration cannot
support GRO_HW, then this makes sense.  But I think it is best to
centralize this logic in ndo_fix_features().  The driver can then call
netdev_update_features() to update all features whenever there are
changes that can affect features.