Re: [PATCH net-next 7/9] devlink: allow registering parameters after the instance

[Leon Romanovsky <leon@kernel.org>]

On Mon, Jan 16, 2023 at 11:33:05AM +0100, Jiri Pirko wrote:
> Sun, Jan 15, 2023 at 09:35:57AM CET, leon@kernel.org wrote:
> >On Fri, Jan 13, 2023 at 08:50:33AM +0100, Jiri Pirko wrote:
> >> Thu, Jan 12, 2023 at 08:58:58PM CET, leon@kernel.org wrote:
> >> >On Thu, Jan 12, 2023 at 03:59:53PM +0100, Jiri Pirko wrote:
> >> >> Thu, Jan 12, 2023 at 08:07:43AM CET, leon@kernel.org wrote:
> >> >> >On Wed, Jan 11, 2023 at 01:29:03PM -0800, Jacob Keller wrote:
> >> >> >> 
> >> >> >> 
> >> >> >> On 1/11/2023 8:45 AM, Jakub Kicinski wrote:
> >> >> >> > On Wed, 11 Jan 2023 10:32:13 +0100 Jiri Pirko wrote:
> >> >> >> >>>> I'm confused. You want to register objects after instance register?  
> >> >> >> >>>
> >> >> >> >>> +1, I think it's an anti-pattern.  
> >> >> >> >>
> >> >> >> >> Could you elaborate a bit please?
> >> >> >> > 
> >> >> >> > Mixing registering sub-objects before and after the instance is a bit
> >> >> >> > of an anti-pattern. Easy to introduce bugs during reload and reset /
> >> >> >> > error recovery. I thought that's what you were saying as well.
> >> >> >> 
> >> >> >> I was thinking of a case where an object is dynamic and might get added
> >> >> >> based on events occurring after the devlink was registered.
> >> >> >> 
> >> >> >> But the more I think about it the less that makes sense. What events
> >> >> >> would cause a whole subobject to be registerd which we wouldn't already
> >> >> >> know about during initialization of devlink?
> >> >> >> 
> >> >> >> We do need some dynamic support because situations like "add port" will
> >> >> >> add a port and then the ports subresources after the main devlink, but I
> >> >> >> think that is already supported well and we'd add the port sub-resources
> >> >> >> at the same time as the port.
> >> >> >> 
> >> >> >> But thinking more on this, there isn't really another good example since
> >> >> >> we'd register things like health reporters, regions, resources, etc all
> >> >> >> during initialization. Each of these sub objects may have dynamic
> >> >> >> portions (ex: region captures, health events, etc) but the need for the
> >> >> >> object should be known about during init time if its supported by the
> >> >> >> device driver.
> >> >> >
> >> >> >As a user, I don't want to see any late dynamic object addition which is
> >> >> >not triggered by me explicitly. As it doesn't make any sense to add
> >> >> >various delays per-vendor/kernel in configuration scripts just because
> >> >> >not everything is ready. Users need predictability, lazy addition of
> >> >> >objects adds chaos instead.
> >> >> >
> >> >> >Agree with Jakub, it is anti-pattern.
> >> >> 
> >> >> Yeah, but, we have reload. And during reload, instance is still
> >> >> registered yet the subobject disappear and reappear. So that would be
> >> >> inconsistent with the init/fini flow.
> >> >> 
> >> >> Perhaps during reload we should emulate complete fini/init notification
> >> >> flow to the user?
> >> >
> >> >"reload" is triggered by me explicitly and I will get success/fail result
> >> >at the end. There is no much meaning in subobject notifications during
> >> >that operation.
> >> 
> >> Definitelly not. User would trigger reload, however another entity
> >> (systemd for example) would listen to the notifications and react
> >> if necessary.
> >
> >Listen yes, however it is not clear if notification sequence should
> >mimic fini/init flow.
> 
> Well, it makes sense to me. Why do you think it should not?

After all this years, I still don't understand the mandate of devlink
reload. It doesn't load/unload driver completely and as such not really
performs probe/remove sequences. There is no requirement from the driver
to do anything even close to fini/init too. 

Sometimes, devlink reload behaves as fini/init, but not always.

This is why I'm not sure.

Thanks

> 
> >
> >Thanks
> >
> >> 
> >> >
> >> >Thanks