On Thu, 2 Feb 2023 09:24:56 +0000 Martin Habets wrote: > > FWIW I'd just take the devl lock in the main driver code. > > devlink should be viewed as a layer between bus and driver rather > > than as another subsystem the driver registers with. Otherwise reloads > > and port creation get awkward. > > I see it a bit differently. For me devlink is another subsystem, it even is > an optional subsystem. > At the moment we don't support devlink port for VFs. If needed we'll add that > at some point, but likely only for newer NICs. That's fine. I believe the structure I suggest is the easiest one to get right, but it's not a hard requirement. > Do you think vDPA and RDMA devices will ever register with devlink? Good question, I can't speak for the entire project but personally I have little interest in interfaces to proprietary world, so I hope not. > At the moment I don't see devlink port ever applying to our older hardware, > like our sfn8000 or X2 cards. I do think devlink info and other commands > could apply more generally. > > There definitely is a need to evolve to another layer between bus and > devices, and devlink can be used to administer that. But that does not > imply the reverse, that all devices register as devlink devices. > For security we would want to limit some operations (such as port creation) > to specific devlink instance(s). For example, normally we would not want a > tennant VM to flash new firmware that applies to the whole NIC. > I hope this makes sense.
