> -----Original Message-----
> From: Michael Chan [mailto:[email protected]]
> Sent: Tuesday, December 05, 2017 4:15 AM
> To: Yuval Mintz <[email protected]>
> Cc: [email protected]; [email protected]; Elior, Ariel
> <[email protected]>; Dept-Eng Everest Linux L2 <Dept-
> [email protected]>
> Subject: Re: [PATCH net-next 4/4] qede: Use NETIF_F_GRO_HW.
>
> On Mon, Dec 4, 2017 at 1:48 PM, Yuval Mintz <[email protected]> wrote:
> >> Advertise NETIF_F_GRO_HW and turn on or off hardware GRO based on
> >> NETIF_F_GRO_FW flag.
> >>
> >> Cc: Ariel Elior <[email protected]>
> >> Cc: [email protected]
> >> Signed-off-by: Michael Chan <[email protected]>
> >> ---
> >> 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;
}
