> -----Original Message----- > From: netdev-ow...@vger.kernel.org <netdev-ow...@vger.kernel.org> On > Behalf Of Edward Cree > Sent: Tuesday, August 6, 2019 4:52 PM > To: David Miller <da...@davemloft.net> > Cc: netdev <netdev@vger.kernel.org>; Eric Dumazet > <eric.duma...@gmail.com>; linux-net-driv...@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
