[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <d7ca6e7a-b80e-12e8-9050-c25b8b92bf26@gmail.com>
Date: Fri, 12 Jul 2019 18:48:29 +0200
From: Eric Dumazet <eric.dumazet@...il.com>
To: Edward Cree <ecree@...arflare.com>,
Eric Dumazet <eric.dumazet@...il.com>,
Paolo Abeni <pabeni@...hat.com>,
David Miller <davem@...emloft.net>
Cc: netdev <netdev@...r.kernel.org>
Subject: Re: [RFC PATCH net-next 0/3] net: batched receive in GRO path
On 7/12/19 5:59 PM, Edward Cree wrote:
> On 10/07/2019 18:39, Eric Dumazet wrote:
>> Holding a small packet in the list up to the point we call busy_poll_stop()
>> will basically make busypoll non working anymore.
>>
>> napi_complete_done() has special behavior when busy polling is active.
> Yep, I get it now, sorry for being dumb :)
> Essentially we're saying that things coalesced by GRO are 'bulk' traffic and
> can wait around,
GRO can still be beneficial even when busypolling, since TCP stack
will send a single ACK back, and a read()/recv() will copy the whole train
instead of a single MSS.
I should have mentioned that we have a patch that I forgot to upstream adding
the PSH flag to all TSO packets, meaning the receiver can automatically learn
the boundary of a GRO packet and not have to wait for the napi->poll() end
(busypolling or not)
> but the rest is the stuff we're polling for for low latency.
> I'm putting a gro_normal_list() call after the trace_napi_poll() in
> napi_busy_loop() and testing that, let's see how it goes...
>
Powered by blists - more mailing lists