From: Jesse Brandeburg <jesse.brandeburg@intel.com>
To: Ido Schimmel <idosch@idosch.org>
Cc: netdev@vger.kernel.org, davem@davemloft.net, kuba@kernel.org,
dsahern@gmail.com, nikolay@nvidia.com, mlxsw@nvidia.com,
Ido Schimmel <idosch@nvidia.com>,
paulmck@kernel.org
Subject: Re: [PATCH net] nexthop: Fix performance regression in nexthop deletion
Date: Fri, 16 Oct 2020 14:46:36 -0700 [thread overview]
Message-ID: <20201016144636.000011cf@intel.com> (raw)
In-Reply-To: <20201016172914.643282-1-idosch@idosch.org>
Ido Schimmel wrote:
> From: Ido Schimmel <idosch@nvidia.com>
>
> While insertion of 16k nexthops all using the same netdev ('dummy10')
> takes less than a second, deletion takes about 130 seconds:
>
> # time -p ip -b nexthop.batch
> real 0.29
> user 0.01
> sys 0.15
>
> # time -p ip link set dev dummy10 down
> real 131.03
> user 0.06
> sys 0.52
snip...
> Since nexthops are always deleted under RTNL, synchronize_net() can be
> used instead. It will call synchronize_rcu_expedited() which only blocks
> for several microseconds as opposed to multiple milliseconds like
> synchronize_rcu().
>
> With this patch deletion of 16k nexthops takes less than a second:
>
> # time -p ip link set dev dummy10 down
> real 0.12
> user 0.00
> sys 0.04
That's a nice result! Well done! I can't really speak to whether or not
there is any horrible side effect of using synchronize_rcu_expedited(),
but FWIW:
Reviewed-by: Jesse Brandeburg <jesse.brandeburg@intel.com>
>
> Tested with fib_nexthops.sh which includes torture tests that prompted
> the initial change:
>
> # ./fib_nexthops.sh
> ...
> Tests passed: 134
> Tests failed: 0
>
> Fixes: 90f33bffa382 ("nexthops: don't modify published nexthop groups")
> Signed-off-by: Ido Schimmel <idosch@nvidia.com>
Nice fix, good commit message, thanks!
> ---
> net/ipv4/nexthop.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/net/ipv4/nexthop.c b/net/ipv4/nexthop.c
> index 8c0f17c6863c..0dc43ad28eb9 100644
> --- a/net/ipv4/nexthop.c
> +++ b/net/ipv4/nexthop.c
> @@ -845,7 +845,7 @@ static void remove_nexthop_from_groups(struct net *net, struct nexthop *nh,
> remove_nh_grp_entry(net, nhge, nlinfo);
>
> /* make sure all see the newly published array before releasing rtnl */
> - synchronize_rcu();
> + synchronize_net();
> }
>
> static void remove_nexthop_group(struct nexthop *nh, struct nl_info *nlinfo)
next prev parent reply other threads:[~2020-10-16 21:46 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-10-16 17:29 [PATCH net] nexthop: Fix performance regression in nexthop deletion Ido Schimmel
2020-10-16 21:46 ` Jesse Brandeburg [this message]
2020-10-17 4:37 ` David Ahern
2020-10-17 9:16 ` Nikolay Aleksandrov
2020-10-20 3:10 ` Jakub Kicinski
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20201016144636.000011cf@intel.com \
--to=jesse.brandeburg@intel.com \
--cc=davem@davemloft.net \
--cc=dsahern@gmail.com \
--cc=idosch@idosch.org \
--cc=idosch@nvidia.com \
--cc=kuba@kernel.org \
--cc=mlxsw@nvidia.com \
--cc=netdev@vger.kernel.org \
--cc=nikolay@nvidia.com \
--cc=paulmck@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.