> -----Original Message----- > From: [email protected] <[email protected]> On > Behalf Of Edward Cree > Sent: Tuesday, August 6, 2019 4:52 PM > To: David Miller <[email protected]> > Cc: netdev <[email protected]>; Eric Dumazet > <[email protected]>; [email protected] > 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
