From: Ido Schimmel <idosch@idosch.org>
To: Hannes Frederic Sowa <hannes@stressinduktion.org>
Cc: Jiri Pirko <jiri@resnulli.us>,
netdev@vger.kernel.org, davem@davemloft.net, idosch@mellanox.com,
eladr@mellanox.com, yotamg@mellanox.com, nogahf@mellanox.com,
arkadis@mellanox.com, ogerlitz@mellanox.com,
roopa@cumulusnetworks.com, dsa@cumulusnetworks.com,
nikolay@cumulusnetworks.com, andy@greyhouse.net,
vivien.didelot@savoirfairelinux.com, andrew@lunn.ch,
f.fainelli@gmail.com, alexander.h.duyck@intel.com,
kuznet@ms2.inr.ac.ru, jmorris@namei.org, yoshfuji@linux-ipv6.org,
kaber@trash.net
Subject: Re: [patch net-next 6/8] ipv4: fib: Add an API to request a FIB dump
Date: Wed, 16 Nov 2016 20:51:03 +0200 [thread overview]
Message-ID: <20161116185103.h3hio4pyrlk2xeol@splinter> (raw)
In-Reply-To: <dcbbcefa-3ca7-c0ed-09a7-1d0e6f96e256@stressinduktion.org>
Hi,
On Wed, Nov 16, 2016 at 06:35:45PM +0100, Hannes Frederic Sowa wrote:
> On 16.11.2016 16:18, Ido Schimmel wrote:
> > On Wed, Nov 16, 2016 at 03:51:01PM +0100, Hannes Frederic Sowa wrote:
> >> On 16.11.2016 15:09, Jiri Pirko wrote:
> >>> From: Ido Schimmel <idosch@mellanox.com>
> >>>
> >>> Commit b90eb7549499 ("fib: introduce FIB notification infrastructure")
> >>> introduced a new notification chain to notify listeners (f.e., switchdev
> >>> drivers) about addition and deletion of routes.
> >>>
> >>> However, upon registration to the chain the FIB tables can already be
> >>> populated, which means potential listeners will have an incomplete view
> >>> of the tables.
> >>>
> >>> Solve that by adding an API to request a FIB dump. The dump itself it
> >>> done using RCU in order not to starve consumers that need RTNL to make
> >>> progress.
> >>>
> >>> Signed-off-by: Ido Schimmel <idosch@mellanox.com>
> >>> Signed-off-by: Jiri Pirko <jiri@mellanox.com>
> >>
> >> Have you looked at potential inconsistencies resulting of RCU walking
> >> the table and having concurrent inserts?
> >
> > Yes. I did try to think about situations in which this approach will
> > fail, but I could only find problems with concurrent removals, which I
> > addressed in 5/8. In case of concurrent insertions, even if you missed
> > the node, you would still get the ENTRY_ADD event to your listener.
>
> Theoretically a node could still be installed while the deletion event
> fired before registering the notifier. E.g. a synchronize_net before
> dumping could help here?
If the deletion event fired for some fib alias, then by 5/8 we are
guaranteed that it was already unlinked from the fib alias list in the
leaf in which it was contained. So, while it's possible we didn't
register our listener in time for the deletion event, we won't traverse
this fib alias while dumping the trie anyway. Did I understand you
correctly?
> I don't know how you prepare the data structures for inserting in into
> the hardware, but if ordering matters, the notifier for a delete event
> can be called before the dump installed the fib entry?
Right. It's possible for the listener to receive a deletion event for a
fib entry it doesn't have, in which case it should just ignore it (as
current listeners do).
next prev parent reply other threads:[~2016-11-16 18:51 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-11-16 14:08 [patch net-next 0/8] ipv4: fib: Allow modules to dump FIB tables Jiri Pirko
2016-11-16 14:08 ` [patch net-next 1/8] ipv4: fib: Export free_fib_info() Jiri Pirko
2016-11-16 14:08 ` [patch net-next 2/8] mlxsw: spectrum_router: Implement FIB offload in delayed work Jiri Pirko
2016-11-16 14:08 ` [patch net-next 3/8] rocker: " Jiri Pirko
2016-11-16 14:08 ` [patch net-next 4/8] ipv4: fib: Convert FIB notification chain to be atomic Jiri Pirko
2016-11-16 14:09 ` [patch net-next 5/8] net: ipv4: Send notifications only after removing FIB alias Jiri Pirko
2016-11-16 14:09 ` [patch net-next 6/8] ipv4: fib: Add an API to request a FIB dump Jiri Pirko
2016-11-16 14:51 ` Hannes Frederic Sowa
2016-11-16 15:18 ` Ido Schimmel
2016-11-16 17:35 ` Hannes Frederic Sowa
2016-11-16 18:51 ` Ido Schimmel [this message]
2016-11-16 19:43 ` Hannes Frederic Sowa
2016-11-16 21:06 ` Ido Schimmel
2016-11-17 13:10 ` Ido Schimmel
2016-11-17 14:36 ` Hannes Frederic Sowa
2016-11-17 16:45 ` David Miller
2016-11-17 17:20 ` Hannes Frederic Sowa
2016-11-17 18:16 ` David Miller
2016-11-17 19:03 ` Hannes Frederic Sowa
2016-11-17 18:32 ` Ido Schimmel
2016-11-17 19:05 ` Hannes Frederic Sowa
2016-11-16 16:27 ` David Miller
2016-11-16 16:42 ` Ido Schimmel
2016-11-16 16:56 ` Hannes Frederic Sowa
2016-11-16 14:09 ` [patch net-next 7/8] mlxsw: spectrum_router: Request a dump of FIB tables during init Jiri Pirko
2016-11-16 14:09 ` [patch net-next 8/8] rocker: " Jiri Pirko
2016-11-16 16:38 ` [patch net-next 0/8] ipv4: fib: Allow modules to dump FIB tables Alexander Duyck
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=20161116185103.h3hio4pyrlk2xeol@splinter \
--to=idosch@idosch.org \
--cc=alexander.h.duyck@intel.com \
--cc=andrew@lunn.ch \
--cc=andy@greyhouse.net \
--cc=arkadis@mellanox.com \
--cc=davem@davemloft.net \
--cc=dsa@cumulusnetworks.com \
--cc=eladr@mellanox.com \
--cc=f.fainelli@gmail.com \
--cc=hannes@stressinduktion.org \
--cc=idosch@mellanox.com \
--cc=jiri@resnulli.us \
--cc=jmorris@namei.org \
--cc=kaber@trash.net \
--cc=kuznet@ms2.inr.ac.ru \
--cc=netdev@vger.kernel.org \
--cc=nikolay@cumulusnetworks.com \
--cc=nogahf@mellanox.com \
--cc=ogerlitz@mellanox.com \
--cc=roopa@cumulusnetworks.com \
--cc=vivien.didelot@savoirfairelinux.com \
--cc=yoshfuji@linux-ipv6.org \
--cc=yotamg@mellanox.com \
/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