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 12:32:19 +0000
From:   "Chopra, Manish" <Manish.Chopra@...ium.com>
To:     Michael Chan <michael.chan@...adcom.com>,
        Yuval Mintz <yuvalm@...lanox.com>
CC:     "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.

> -----Original Message-----
> From: Michael Chan [mailto:michael.chan@...adcom.com]
> Sent: Tuesday, December 05, 2017 4:15 AM
> To: Yuval Mintz <yuvalm@...lanox.com>
> Cc: davem@...emloft.net; 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 Mon, Dec 4, 2017 at 1:48 PM, Yuval Mintz <yuvalm@...lanox.com> wrote:
> >> Advertise NETIF_F_GRO_HW and turn on or off hardware GRO based on
> >> NETIF_F_GRO_FW flag.
> >>
> >> Cc: Ariel Elior <Ariel.Elior@...ium.com>
> >> Cc: everest-linux-l2@...ium.com
> >> Signed-off-by: Michael Chan <michael.chan@...adcom.com>
> >> ---
> >>  drivers/net/ethernet/qlogic/qede/qede_filter.c | 9 ++-------
> >>  drivers/net/ethernet/qlogic/qede/qede_main.c   | 4 ++--
> >>  2 files changed, 4 insertions(+), 9 deletions(-)
> >>
> >> diff --git a/drivers/net/ethernet/qlogic/qede/qede_filter.c
> >> b/drivers/net/ethernet/qlogic/qede/qede_filter.c
> >> index c1a0708..7ee49b4 100644
> >> --- a/drivers/net/ethernet/qlogic/qede/qede_filter.c
> >> +++ b/drivers/net/ethernet/qlogic/qede/qede_filter.c
> >> @@ -901,13 +901,8 @@ int qede_set_features(struct net_device *dev,
> >> netdev_features_t features)
> >>       netdev_features_t changes = features ^ dev->features;
> >>       bool need_reload = false;
> >>
> >> -     /* No action needed if hardware GRO is disabled during driver load */
> >> -     if (changes & NETIF_F_GRO) {
> >> -             if (dev->features & NETIF_F_GRO)
> >> -                     need_reload = !edev->gro_disable;
> >> -             else
> >> -                     need_reload = edev->gro_disable;
> >> -     }
> >> +     if (changes & NETIF_F_GRO_HW)
> >> +             need_reload = true;
> >
> > This doesn't look right; edev->gro_disable can change due to other
> > conditions as well - otherwise, it would have been synonymous with
> > (dev->features & NETIF_F_GRO).
> >
> 
> Feel free to modify the patch.  The idea is for the driver to determine in
> ndo_fix_features()/ndo_set_features() if GRO_HW can be enabled.  For things
> like generic XDP, I think we can add code to centrally disable GRO_HW and not
> have to worry about that in the driver.

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;
}

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ