[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20191002.114709.1902747897923909745.davem@davemloft.net>
Date: Wed, 02 Oct 2019 11:47:09 -0400 (EDT)
From: David Miller <davem@...emloft.net>
To: jiri@...nulli.us
Cc: netdev@...r.kernel.org, idosch@...lanox.com, pabeni@...hat.com,
edumazet@...gle.com, petrm@...lanox.com, sd@...asysnail.net,
f.fainelli@...il.com, stephen@...workplumber.org,
mlxsw@...lanox.com, andrew@...n.ch
Subject: Re: [patch net-next 2/3] net: introduce per-netns netdevice
notifiers
From: Jiri Pirko <jiri@...nulli.us>
Date: Mon, 30 Sep 2019 10:15:10 +0200
> From: Jiri Pirko <jiri@...lanox.com>
>
> Often the code for example in drivers is interested in getting notifier
> call only from certain network namespace. In addition to the existing
> global netdevice notifier chain introduce per-netns chains and allow
> users to register to that. Eventually this would eliminate unnecessary
> overhead in case there are many netdevices in many network namespaces.
>
> Signed-off-by: Jiri Pirko <jiri@...lanox.com>
Ok, so there was a discussion about stop semantics.
Honestly, I think that's fine.
Stop means the operation cannot be performed and whoever is firing off
the notifier will have to fail and undo the config change being
attempted.
In that context, it doesn't matter who or where in the chain we
trigger the stop.
Given all of that I am pretty sure this change is fine and I will
add it to net-next. We can fix any actual semantic problems this
might introduce as a follow-on.
Powered by blists - more mailing lists