On 01.04.2019 19:31, Edward Cree wrote: > On 01/04/2019 18:14, David Miller wrote: >> From: Eric Dumazet <eric.duma...@gmail.com> >> Date: Mon, 1 Apr 2019 02:17:12 -0700 >> >>> This means no GRO at all >> I do not think that is true as the SKB list layer does queue up to >> GRO. > No, Eric is right; the current list layer bypasses GRO completely. > > netif_receive_skb_list() ends up doing the same things netif_receive_skb() > would do on each SKB in the list, and that does not include GRO. > (For this reason the sfc driver only uses netif_receive_skb_list() for > non-TCP packets; TCP packets go to napi_gro_frags().) > I had a patch series to add napi_gro_receive_list() which would use the > SKB list layer to handle the packets GRO didn't coalesce ([1]) but the > performance tests I ran were inconclusive and it never got applied. > > -Ed > > [1]: https://marc.info/?l=linux-netdev&m=154221888012410&w=2 > Patch 0a25d92c6f4f ("dpaa2-eth: use netif_receive_skb_list") was well perceived [1], therefore I was under the assumption that netif_receive_skb_list is kind of successor for napi_gro_receive(). Does what you say apply to that patch too?
Based on feedback so far it seems to best if I revert the patch. Heiner [1] https://patchwork.ozlabs.org/patch/1064334/
