[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <BN3PR0701MB1412F0BAAFA95465F32BB257893D0@BN3PR0701MB1412.namprd07.prod.outlook.com>
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