From: David Miller <davem@davemloft.net>
To: fw@strlen.de
Cc: netdev@vger.kernel.org
Subject: Re: [PATCH net-next 0/7] rtnetlink: allow to run selected handlers without rtnl
Date: Tue, 08 Aug 2017 21:33:29 -0700 (PDT) [thread overview]
Message-ID: <20170808.213329.522107918983433411.davem@davemloft.net> (raw)
In-Reply-To: <20170808160236.28562-1-fw@strlen.de>
From: Florian Westphal <fw@strlen.de>
Date: Tue, 8 Aug 2017 18:02:29 +0200
> Unfortunately RTNL mutex is a performance issue, e.g. a cpu adding
> an ip address prevents other cpus from seemingly unrelated tasks
> such as dumping tc classifiers.
It is related if somehow the TC entries refer to IP addresses.
Someone could create something like that.
> Initial no-rtnl spots are ip6 fib add/del and netns new/getid.
I could see the netns stuff being ok, but IPv6 route add/del I'm
not so sure of.
Because of things like nexthops etc. there are dependencies on
other configuration things.
That's the whole reason we have this unfortunate global
synchronization point. If I'm changing some aspect of network
configuration, I know I can atomically test any piece of networking
configuration state.
If I test a network address to make sure I can properly reacy X and
use X as a nexthop in the route I'm adding, it will be there
throughout the entire operation.
There really is a hierachy of these dependencies. Device state, up
to neighbour table state, up to protocol address state, up to routes,
up to FIB tables, etc. etc. etc.
I'd really like to make this operate more freely, but this is an
extremely delicate area which has been bottled up like this for
two decades so good luck :-)
next prev parent reply other threads:[~2017-08-09 4:33 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-08-08 16:02 [PATCH net-next 0/7] rtnetlink: allow to run selected handlers without rtnl Florian Westphal
2017-08-08 16:02 ` [PATCH net-next 1/7] rtnetlink: call rtnl_calcit directly Florian Westphal
2017-08-08 16:02 ` [PATCH net-next 2/7] rtnetlink: make rtnl_register accept a flags parameter Florian Westphal
2017-08-08 16:02 ` [PATCH net-next 3/7] rtnetlink: add reference counting to prevent module unload while dump is in progress Florian Westphal
2017-08-08 16:02 ` [PATCH net-next 4/7] rtnetlink: small rtnl lock pushdown Florian Westphal
2017-08-08 16:02 ` [PATCH net-next 5/7] rtnetlink: protect handler table with rcu Florian Westphal
2017-08-08 16:02 ` [PATCH net-next 6/7] rtnetlink: add and use RTNL_FLAG_DOIT_UNLOCKED Florian Westphal
2017-08-08 16:02 ` [PATCH net-next 7/7] net: call newid/getid without rtnl mutex held Florian Westphal
2017-08-09 4:33 ` David Miller [this message]
2017-08-09 8:19 ` [PATCH net-next 0/7] rtnetlink: allow to run selected handlers without rtnl Florian Westphal
2017-08-09 16:41 ` David Miller
2017-08-09 16:42 ` David Miller
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=20170808.213329.522107918983433411.davem@davemloft.net \
--to=davem@davemloft.net \
--cc=fw@strlen.de \
--cc=netdev@vger.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).