From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from shards.monkeyblade.net ([184.105.139.130]:56610 "EHLO shards.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752298AbeDJRQx (ORCPT ); Tue, 10 Apr 2018 13:16:53 -0400 Date: Tue, 10 Apr 2018 13:16:49 -0400 (EDT) Message-Id: <20180410.131649.583776764903333305.davem@davemloft.net> To: saeedm@mellanox.com Cc: netdev@vger.kernel.org Subject: Re: [RFC net-next 1/2] net: net-porcfs: Reduce rcu lock critical section From: David Miller In-Reply-To: <20180410170812.18905-1-saeedm@mellanox.com> References: <20180410170812.18905-1-saeedm@mellanox.com> Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: netdev-owner@vger.kernel.org List-ID: From: Saeed Mahameed Date: Tue, 10 Apr 2018 10:08:11 -0700 > The current net proc fs sequence file implementation to show current > namespace netdevs list statistics and mc lists holds the rcu lock > throughout the whole process, from dev seq start up to dev seq stop. > > This is really greedy and demanding from device drivers since > ndo_get_stats64 called from dev_seq_show while the rcu lock is held. > > The rcu lock is needed to guarantee that device chain is not modified > while the dev sequence file is walking through it and handling the > netdev in the same time. > > To minimize this critical section and drastically reduce the time rcu lock > is being held, all we need is to grab the rcu lock only for the brief > moment where we are looking for the next netdev to handle, if found, > dev_hold it to guarantee it kept alive while accessed later in seq show > callback and release the rcu lock immediately. > > The current netdev being handled will be released "dev_put" when the seq next > callback is called or dev seq stop is called. > > Signed-off-by: Saeed Mahameed The tradeoff here is that now you are doing two unnecessary atomic operations per stats dump. That is what the RCU lock allows us to avoid.