[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAM_iQpWBATQUcTEg1o_mrA+zoH0KOh0Kpnmt+GgCLy+K3d=5_g@mail.gmail.com>
Date: Mon, 14 Nov 2016 21:21:28 -0800
From: Cong Wang <xiyou.wangcong@...il.com>
To: Eric Dumazet <eric.dumazet@...il.com>
Cc: "Eric W. Biederman" <ebiederm@...ssion.com>,
David Miller <davem@...emloft.net>,
"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>,
Rolf Neugebauer <rolf.neugebauer@...ker.com>,
Linux Kernel Network Developers <netdev@...r.kernel.org>,
Justin Cormack <justin.cormack@...ker.com>,
Ian Campbell <ian.campbell@...ker.com>,
Eric Dumazet <edumazet@...gle.com>
Subject: Re: [PATCH net] gro_cells: mark napi struct as not busy poll candidates
On Mon, Nov 14, 2016 at 4:28 PM, Eric Dumazet <eric.dumazet@...il.com> wrote:
> From: Eric Dumazet <edumazet@...gle.com>
>
> Rolf Neugebauer reported very long delays at netns dismantle.
>
> Eric W. Biederman was kind enough to look at this problem
> and noticed synchronize_net() occurring from netif_napi_del() that was
> added in linux-4.5
>
> Busy polling makes no sense for tunnels NAPI.
> If busy poll is used for sessions over tunnels, the poller will need to
> poll the physical device queue anyway.
>
> netif_tx_napi_add() could be used here, but function name is misleading,
> and renaming it is not stable material, so set NAPI_STATE_NO_BUSY_POLL
> bit directly.
>
> This will avoid inserting gro_cells napi structures in napi_hash[]
> and avoid the problematic synchronize_net() (per possible cpu) that
> Rolf reported.
>
> Fixes: 93d05d4a320c ("net: provide generic busy polling to all NAPI drivers")
> Signed-off-by: Eric Dumazet <edumazet@...gle.com>
> Reported-by: Rolf Neugebauer <rolf.neugebauer@...ker.com>
> Reported-by: Eric W. Biederman <ebiederm@...ssion.com>
Acked-by: Cong Wang <xiyou.wangcong@...il.com>
Powered by blists - more mailing lists