[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <5697DF47-5CCB-41F3-9BD1-62DE42AD61B8@gmail.com>
Date: Thu, 17 Nov 2016 16:31:19 -0800
From: Jarno Rajahalme <jarno.rajahalme@...il.com>
To: Eric Dumazet <eric.dumazet@...il.com>
Cc: "Eric W. Biederman" <ebiederm@...ssion.com>,
"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>,
Cong Wang <xiyou.wangcong@...il.com>,
Rolf Neugebauer <rolf.neugebauer@...ker.com>,
LKML <linux-kernel@...r.kernel.org>,
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: Long delays creating a netns after deleting one (possibly RCU related)
> On Nov 14, 2016, at 3:09 PM, Eric Dumazet <eric.dumazet@...il.com> wrote:
>
> On Mon, 2016-11-14 at 14:46 -0800, Eric Dumazet wrote:
>> On Mon, 2016-11-14 at 16:12 -0600, Eric W. Biederman wrote:
>>
>>> synchronize_rcu_expidited is not enough if you have multiple network
>>> devices in play.
>>>
>>> Looking at the code it comes down to this commit, and it appears there
>>> is a promise add rcu grace period combining by Eric Dumazet.
>>>
>>> Eric since people are hitting noticable stalls because of the rcu grace
>>> period taking a long time do you think you could look at this code path
>>> a bit more?
>>>
>>> commit 93d05d4a320cb16712bb3d57a9658f395d8cecb9
>>> Author: Eric Dumazet <edumazet@...gle.com>
>>> Date: Wed Nov 18 06:31:03 2015 -0800
>>
>> Absolutely, I will take a loop asap.
>
> The worst offender should be fixed by the following patch.
>
> busy poll needs to poll the physical device, not a virtual one...
>
> diff --git a/include/net/gro_cells.h b/include/net/gro_cells.h
> index d15214d673b2e8e08fd6437b572278fb1359f10d..2a1abbf8da74368cd01adc40cef6c0644e059ef2 100644
> --- a/include/net/gro_cells.h
> +++ b/include/net/gro_cells.h
> @@ -68,6 +68,9 @@ static inline int gro_cells_init(struct gro_cells *gcells, struct net_device *de
> struct gro_cell *cell = per_cpu_ptr(gcells->cells, i);
>
> __skb_queue_head_init(&cell->napi_skbs);
> +
> + set_bit(NAPI_STATE_NO_BUSY_POLL, &cell->napi.state);
> +
> netif_napi_add(dev, &cell->napi, gro_cell_poll, 64);
> napi_enable(&cell->napi);
> }
>
This solved a ~20 second slowdown between OVS datapath unit tests for me.
Jarno
Powered by blists - more mailing lists