netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jiri Pirko <jiri@resnulli.us>
To: David Ahern <dsahern@gmail.com>
Cc: netdev@vger.kernel.org, davem@davemloft.net,
	jakub.kicinski@netronome.com, saeedm@mellanox.com,
	leon@kernel.org, tariqt@mellanox.com, ayal@mellanox.com,
	vladbu@mellanox.com, michaelgur@mellanox.com, moshe@mellanox.com,
	mlxsw@mellanox.com
Subject: Re: [patch net-next 0/4] net: allow per-net notifier to follow netdev into namespace
Date: Tue, 7 Jan 2020 10:11:30 +0100	[thread overview]
Message-ID: <20200107091130.GB2185@nanopsycho> (raw)
In-Reply-To: <b3fe2a66-baaf-86bb-5347-1ffcaadb3d14@gmail.com>

Mon, Jan 06, 2020 at 05:37:21PM CET, dsahern@gmail.com wrote:
>On 1/6/20 2:15 AM, Jiri Pirko wrote:
>> 
>> I do not follow. This patchset assures that driver does not get
>> notification of namespace it does not care about. I'm not sure what do
>> you mean by "half of the problem".
>
>originally, notifiers were only global. drivers registered for them, got
>the replay of existing data, and notifications across namespaces.

Not sure what do you mean by "replay of existing data".


>
>You added code to allow drivers to register for events in a specific
>namespace.

For some drivers, like "mlxsw" this is just enough as it does not
support move of netdevices to different namespaces and the namespace of
all netdevices is taken according to namespace of parent devlink
instance.


>
>Now you are saying that is not enough as devices can be moved from one
>namespace to another and you want core code to automagically register a
>driver for events as its devices are moved.
>
>My point is if a driver is trying to be efficient and not handle events
>in namespaces it does not care about (the argument for per-namespace
>notifiers) then something needs to track that a driver no longer cares
>about events in a given namespace once all devices are moved out of Only
>the driver knows that and IMHO the driver should be the one managing
>what namespaces it wants events.

Definitelly. This would be the case for per-driver notifiers.
However, the ones in mlx5 I'm taking care of are per-netdevice
notifiers. Each netdev registers a separate notifier.


>
>Example:
>driver A has 2 devices eth0, eth1. It registers for events ONLY in
>init_net. eth0 is moved to ns0. eth1 is moved to ns1. On the move, core
>code registers driver A for events in ns0 and ns1.
>
>Driver A now no longer cares about events in init_net, yet it still
>receives them. If this is not a big concern for driver A, then why the
>namespace only registration? ie., just use the global and move on. If it
>is a concern (your point in this thread), you have not solved the
>unregister problem.

Wait, why do you think that there is a "unregister problem"?
move_netdevice_notifiers_dev_net() unregisters from the original netns.


>
>ie., I don't like the automagic registration in the new namespace.
>drivers should be explicit about what it wants.
>
>> 
>> 
>>> driver cares for granularity, it can deal with namespace changes on its
>>> own. If that's too much, use the global registration.
>

      reply	other threads:[~2020-01-07  9:11 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-12-20 12:35 [patch net-next 0/4] net: allow per-net notifier to follow netdev into namespace Jiri Pirko
2019-12-20 12:35 ` [patch net-next 1/4] net: call call_netdevice_unregister_net_notifiers from unregister Jiri Pirko
2019-12-20 17:59   ` David Ahern
2019-12-20 12:35 ` [patch net-next 2/4] net: push code from net notifier reg/unreg into helpers Jiri Pirko
2019-12-20 18:07   ` David Ahern
2019-12-21  8:07     ` Jiri Pirko
2019-12-20 12:35 ` [patch net-next 3/4] net: introduce dev_net notifier register/unregister variants Jiri Pirko
2019-12-20 19:29   ` Saeed Mahameed
2019-12-21  8:21     ` Jiri Pirko
2019-12-20 12:35 ` [patch net-next 4/4] mlx5: Use dev_net netdevice notifier registrations Jiri Pirko
2019-12-20 18:30 ` [patch net-next 0/4] net: allow per-net notifier to follow netdev into namespace David Ahern
2019-12-21  8:14   ` Jiri Pirko
2019-12-22  4:57     ` David Ahern
2020-01-06  9:15       ` Jiri Pirko
2020-01-06 16:37         ` David Ahern
2020-01-07  9:11           ` Jiri Pirko [this message]

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=20200107091130.GB2185@nanopsycho \
    --to=jiri@resnulli.us \
    --cc=ayal@mellanox.com \
    --cc=davem@davemloft.net \
    --cc=dsahern@gmail.com \
    --cc=jakub.kicinski@netronome.com \
    --cc=leon@kernel.org \
    --cc=michaelgur@mellanox.com \
    --cc=mlxsw@mellanox.com \
    --cc=moshe@mellanox.com \
    --cc=netdev@vger.kernel.org \
    --cc=saeedm@mellanox.com \
    --cc=tariqt@mellanox.com \
    --cc=vladbu@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;
as well as URLs for NNTP newsgroup(s).