On Fri, 13 Jul 2018 15:19:40 +0100
Edward Cree <ec...@solarflare.com> wrote:
> On 12/07/18 21:10, Or Gerlitz wrote:
> > On Wed, Jul 11, 2018 at 11:06 PM, Jesper Dangaard Brouer
> > <bro...@redhat.com> wrote:
> >> One reason I didn't "just" send a patch, is that Edward so-fare only
> >> implemented netif_receive_skb_list() and not napi_gro_receive_list().
> > sfc does't support gro?! doesn't make sense.. Edward?
> sfc has a flag EFX_RX_PKT_TCP set according to bits in the RX event, we
> call napi_{get,gro}_frags() (via efx_rx_packet_gro()) for TCP packets and
> netif_receive_skb() (or now the list handling) (via efx_rx_deliver()) for
> non-TCP packets. So we avoid the GRO overhead for non-TCP workloads.
>
> > Same TCP performance
> >
> > with GRO and no rx-batching
> >
> > or
> >
> > without GRO and yes rx-batching
> >
> > is by far not intuitive result
>
> I'm also surprised by this. If I can find the time I'll try to do similar
> experiments on sfc.
> Jesper, are the CPU utilisations similar in both cases?
The CPU util is very different.
With enabled-GRO netperf CPU is only 60.89% loaded in %sys
With napi_gro_receive_list it is almost 100% loaded
Same CPU-load with just disabling GRO.
> You're sure your stream isn't TX-limited?
It might be the case, as the netperf sender HW is not as new as the
device under test. And the 60% load and idle cycles in case of GRO,
does indicate this is the case.
--
Best regards,
Jesper Dangaard Brouer
MSc.CS, Principal Kernel Engineer at Red Hat
LinkedIn: http://www.linkedin.com/in/brouer
