Thread (28 messages) 28 messages, 4 authors, 2019-08-06

Re: [patch net-next v2 1/3] net: devlink: allow to change namespaces

From: Jiri Pirko <jiri@resnulli.us>
Date: 2019-08-05 05:54:28

Fri, Aug 02, 2019 at 05:45:36PM CEST, dsahern@gmail.com wrote:
On 8/2/19 1:48 AM, Jiri Pirko wrote:
quoted
Wed, Jul 31, 2019 at 09:58:10PM CEST, dsahern@gmail.com wrote:
quoted
On 7/31/19 1:46 PM, David Ahern wrote:
quoted
On 7/31/19 1:45 PM, Jiri Pirko wrote:
quoted
quoted
check. e.g., what happens if a resource controller has been configured
for the devlink instance and it is moved to a namespace whose existing
config exceeds those limits?
It's moved with all the values. The whole instance is moved.
The values are moved, but the FIB in a namespace could already contain
more routes than the devlink instance allows.
From a quick test your recent refactoring to netdevsim broke the
resource controller. It was, and is intended to be, per network namespace.
unifying devlink instances with network namespace in netdevsim was
really odd. Netdevsim is also a device, like any other. With other
devices, you do not do this so I don't see why to do this with netdevsim.

Now you create netdevsim instance in sysfs, there is proper bus probe
mechanism done, there is a devlink instance created for this device,
there are netdevices and devlink ports created. Same as for the real
hardware.

Honestly, creating a devlink instance per-network namespace
automagically, no relation to netdevsim devices, that is simply wrong.
There should be always 1:1 relationshin between a device and devlink
instance.
Jiri: prior to your recent change netdevsim had a fib resource
controller per network namespace. Please return that behavior or revert
the change.
There was implicit devlink instance creation per-namespace. No relation
any actual device. It was wrong and misuse of devlink.

Now you have 1 devlink instance per 1 device as it should be. Also, you
have fib resource control for this device, also as it is done for real
devices, like mlxsw.

Could you please describe your usecase? Perhaps we can handle
it differently.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help