[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Y8AgaVjRGgWtbq5X@nanopsycho>
Date: Thu, 12 Jan 2023 15:59:53 +0100
From: Jiri Pirko <jiri@...nulli.us>
To: Leon Romanovsky <leon@...nel.org>
Cc: Jacob Keller <jacob.e.keller@...el.com>,
Jakub Kicinski <kuba@...nel.org>, davem@...emloft.net,
netdev@...r.kernel.org, edumazet@...gle.com, pabeni@...hat.com
Subject: Re: [PATCH net-next 7/9] devlink: allow registering parameters after
the instance
Thu, Jan 12, 2023 at 08:07:43AM CET, leon@...nel.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?
Powered by blists - more mailing lists