On 11/15/2018 01:45 PM, Edward Cree wrote: > > If napi->poll() is only handling one packet, surely GRO can't do anything > useful either? (AIUI at the end of the poll the GRO lists get flushed.) That is my point. Adding yet another layer that will add no gain but add more waste of cpu cycles. In fact I know many people disabling GRO in some cases because it adds ~5% penalty for traffic that is not aggregated. > Is it maybe a sign that you're just spreading over too many queues?? Not really. You also want to be able to receive more traffic if the need comes. Most NIC share the same IRQ for one TX/RX queue, and you might have an imbalance between TX and RX load.
- [PATCH v3 net-next 0/4] net: batched receive in GRO path Edward Cree
- [PATCH v3 net-next 1/4] net: introduce list entry point ... Edward Cree
- [PATCH v3 net-next 2/4] sfc: use batched receive for GRO Edward Cree
- [PATCH v3 net-next 4/4] net/core: handle GRO_NORMAL skbs... Edward Cree
- [PATCH v3 net-next 3/4] net: make listified RX functions... Edward Cree
- Re: [PATCH v3 net-next 0/4] net: batched receive in GRO ... Eric Dumazet
- Re: [PATCH v3 net-next 0/4] net: batched receive in ... Edward Cree
- Re: [PATCH v3 net-next 0/4] net: batched receive... Eric Dumazet
- Re: [PATCH v3 net-next 0/4] net: batched rec... Edward Cree
- Re: [PATCH v3 net-next 0/4] net: batche... Eric Dumazet
- Re: [PATCH v3 net-next 0/4] net: ba... Edward Cree
- Re: [PATCH v3 net-next 0/4] net... Eric Dumazet
- Re: [PATCH v3 net-next 0/4] net: batched receive in GRO ... Edward Cree