On 15/11/18 22:01, Eric Dumazet wrote: > 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. Does there maybe need to be an (ethtool -K) option to disable batch receive, then, for this kind of user?
>> 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. Oh I see, this is about using less CPU when not maxed out, rather than increasing the maximum performance. I did see a 6% RXCPU usage increase in the "TCP RR, GRO on" test. (Before= 188.7%, after=200%, Welch p<0.001, Cohen's d=6.2.) I'll try adding a "skip batching for short lists" and retest, see if that improves matters.
