[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <a6faf533-6dd3-d7d7-9464-1fe87d0ac7fc@solarflare.com>
Date: Fri, 9 Aug 2019 18:32:02 +0100
From: Edward Cree <ecree@...arflare.com>
To: Ioana Ciocoi Radulescu <ruxandra.radulescu@....com>
CC: David Miller <davem@...emloft.net>,
netdev <netdev@...r.kernel.org>,
"Eric Dumazet" <eric.dumazet@...il.com>,
"linux-net-drivers@...arflare.com" <linux-net-drivers@...arflare.com>
Subject: Re: [PATCH v3 net-next 0/3] net: batched receive in GRO path
On 09/08/2019 18:14, Ioana Ciocoi Radulescu wrote:
> Hi Edward,
>
> I'm probably missing a lot of context here, but is there a reason
> this change targets only the napi_gro_frags() path and not the
> napi_gro_receive() one?
> I'm trying to understand what drivers that don't call napi_gro_frags()
> should do in order to benefit from this batching feature.
The sfc driver (which is what I have lots of hardware for, so I can
test it) uses napi_gro_frags().
It should be possible to do a similar patch to napi_gro_receive(),
if someone wants to put in the effort of writing and testing it.
However, there are many more callers, so more effort required to
make sure none of them care whether the return value is GRO_DROP
or GRO_NORMAL (since the listified version cannot give that
indication).
Also, the guidance from Eric is that drivers seeking high performance
should use napi_gro_frags(), as this allows GRO to recycle the SKB.
All of this together means I don't plan to submit such a patch; I
would however be happy to review a patch if someone else writes one.
HTH,
-Ed
Powered by blists - more mailing lists