Sun, Mar 25, 2018 at 04:24:11PM CEST, d...@cumulusnetworks.com wrote: >On 3/24/18 10:02 AM, Jiri Pirko wrote: >>>>>>>> >>>>>>>> Wait a second. What do you mean by "per-network namespace"? Devlink >>>>>>>> instance is always associated with one physical device. Like an ASIC. >>>>>>>> >>>>>>>> >>>>>>>>> has a net entry, the simplest design is to put it into the namespace >>>>>>>>> of >>>>>>>>> the controller. Without it, controlling resource sizes in namespace >>>>>>>>> 'foobar' has to be done from init_net, which is just wrong. >>>>>>> >>>>>>> you need to look at how netdevsim creates a device per netdevice. >>>>>> >>>>>> That means one devlink instance for each netdevsim device, doesn't it? >>>>>> >>>>> >>>>> yes. >>>> >>>> Still not sure how to handle namespaces in devlink. Originally, I >>>> thought it would be okay to leave all devlink instances in init_ns. >>>> Because what happens if you move netdev to another namespace? Should the >>>> devlink move as well? What if you have multiple ports, each in different >>>> namespace. Can user move devlink instance to another namespace? Etc. >>>> >>> >>> The devlink instance is associated with a 'struct device' and those do >>> not change namespaces AFAIK. >> >> Yeah. But you put devlink instance into namespace according to struct >> net_device. That is mismatch. >> > >New netdevsim netdevice creates a new 'struct device' which creates a >new devlink instance. The namespace the netdev is created in is then >passed to the devlink instance. Yes, the netdev could change namespaces, >but that is something we can easily prevent if it has a devlink instance. > >But really, we are way down a tangent with respect to the intent of this >patch set. I am fine with limiting the example resource controller to
I know. That is just something that I spotted :)
