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

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]

Message-ID: <willemdebruijn.kernel.3877052beef72@gmail.com>
Date: Sun, 30 Nov 2025 09:56:24 -0500
From: Willem de Bruijn <willemdebruijn.kernel@...il.com>
To: Jakub Kicinski <kuba@...nel.org>, 
 Willem de Bruijn <willemdebruijn.kernel@...il.com>
Cc: davem@...emloft.net, 
 netdev@...r.kernel.org, 
 edumazet@...gle.com, 
 pabeni@...hat.com, 
 andrew+netdev@...n.ch, 
 horms@...nel.org, 
 shuah@...nel.org, 
 sdf@...ichev.me, 
 linux-kselftest@...r.kernel.org
Subject: Re: [PATCH net-next 2/2] selftests: drv-net: gro: run the test
 against HW GRO and LRO

Jakub Kicinski wrote:
> 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.

I think that's fair.

But from reading the code I don't see how disabling NETIF_F_GRO also
disables NETIF_F_GRO_HW. And indeed I just tested on one (admittedly
not latest upstream) IDPF driver and it does not.

Also, the XDP limitation is perhaps vestigial and could go away, since
generic XDP appears to support XDP frags (AKA multibuffer XDP), as of
commit e6d5dbdd20aa ("xdp: add multi-buff support for xdp running in
generic mode").