Alexander Lobakin <aleksander.lobakin@xxxxxxxxx> writes: > In fact, these two are not tied closely to each other. The only > requirements to GRO are to use it in the BH context and have some > sane limits on the packet batches, e.g. NAPI has a limit of its > budget (64/8/etc.). > Move purely GRO fields into a new tagged group, &gro_node. Embed it > into &napi_struct and adjust all the references. napi_id doesn't > really belong to GRO, but: > > 1. struct gro_node has a 4-byte padding at the end anyway. If you > leave napi_id outside, struct napi_struct takes additional 8 bytes > (u32 napi_id + another 4-byte padding). > 2. gro_receive_skb() uses it to mark skbs. We don't want to split it > into two functions or add an `if`, as this would be less efficient, > but we need it to be NAPI-independent. The current approach doesn't > change anything for NAPI-backed GROs; for standalone ones (which > are less important currently), the embedded napi_id will be just > zero => no-op. > > Three Ethernet drivers use napi_gro_flush() not really meant to be > exported, so move it to <net/gro.h> and add that include there. > napi_gro_receive() is used in more than 100 drivers, keep it > in <linux/netdevice.h>. > This does not make GRO ready to use outside of the NAPI context > yet. > > Signed-off-by: Alexander Lobakin <aleksander.lobakin@xxxxxxxxx> > Tested-by: Daniel Xu <dxu@xxxxxxxxx> Reviewed-by: Toke Høiland-Jørgensen <toke@xxxxxxxxxx>
