Re: [PATCH net-next 2/2] selftests: drv-net: gro: run the test against HW GRO and LRO

[Jakub Kicinski <kuba@kernel.org>]

On Fri, 28 Nov 2025 15:42:40 -0500 Willem de Bruijn wrote:
> > +    elif mode == "lro":
> > +        _set_ethtool_feat(cfg.ifname, cfg.feat,
> > +                          {"generic-receive-offload": False,  
> 
> So GRO off disables HW_GRO, but not LRO? That difference is behavior
> is confusing. Could we still see this as a regression and make the
> ethtool HW_GRO feature equally independent from SW_GRO?

I couldn't convince myself that it's justified. Of course it would have
made testing a lot easier. But apart from that - what's your reading of
the status quo? Working backwards from were we ended up (and I
haven't dug into the git history) I'm guessing that LRO disable is used
to prevent changing geometry of the packets. GRO would presumably be
disabled when user knows that it will be ineffective, to save the cost.
Or when some portion of the stack (XDP?) can't deal with super frames.

If those are the reasons, practically, I don't see why user would want
HW GRO without SW. Ever since we allowed SW GRO to re-GRO HW GRO'ed
frames it's always better to leave SW enabled. HW leaves a lot of
aggregation opportunities on the table.

I concluded that changing the current behavior would not help any real
life scenario, just testing. LMK if you see one or the inconsistency
is a big enough reason.