-----Original Message-----
From: netdev-owner@vger.kernel.org <redacted> On
Behalf Of Edward Cree
Sent: Tuesday, August 6, 2019 4:52 PM
To: David Miller <davem@davemloft.net>
Cc: netdev <redacted>; Eric Dumazet
[off-list ref]; linux-net-drivers@solarflare.com
Subject: [PATCH v3 net-next 0/3] net: batched receive in GRO path

This series listifies part of GRO processing, in a manner which allows those
 packets which are not GROed (i.e. for which dev_gro_receive returns
 GRO_NORMAL) to be passed on to the listified regular receive path.
dev_gro_receive() itself is not listified, nor the per-protocol GRO
 callback, since GRO's need to hold packets on lists under napi->gro_hash
 makes keeping the packets on other lists awkward, and since the GRO control
 block state of held skbs can refer only to one 'new' skb at a time.
Instead, when napi_frags_finish() handles a GRO_NORMAL result, stash the skb
 onto a list in the napi struct, which is received at the end of the napi
 poll or when its length exceeds the (new) sysctl net.core.gro_normal_batch.

Hi Edward,

I'm probably missing a lot of context here, but is there a reason
this change targets only the napi_gro_frags() path and not the
napi_gro_receive() one?

I'm trying to understand what drivers that don't call napi_gro_frags()
should do in order to benefit from this batching feature.

Thanks,
Ioana