[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <oqeog7ztpavz657mxmhwvyzbay5e5znc6uezu2doqocftzngn6@kht552qiryha>
Date: Fri, 28 Feb 2025 13:28:46 +0100
From: Jiri Pirko <jiri@...nulli.us>
To: Przemek Kitszel <przemyslaw.kitszel@...el.com>
Cc: Saeed Mahameed <saeed@...nel.org>, Jiri Pirko <jiri@...dia.com>,
Saeed Mahameed <saeedm@...dia.com>, "David S. Miller" <davem@...emloft.net>,
Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>,
Eric Dumazet <edumazet@...gle.com>, netdev@...r.kernel.org, Tariq Toukan <tariqt@...dia.com>,
Gal Pressman <gal@...dia.com>, Leon Romanovsky <leonro@...dia.com>
Subject: Re: [PATCH net-next 07/14] devlink: Implement port params
registration
Fri, Feb 28, 2025 at 12:58:38PM +0100, przemyslaw.kitszel@...el.com wrote:
>On 2/28/25 03:12, Saeed Mahameed wrote:
>> From: Saeed Mahameed <saeedm@...dia.com>
>>
>> Port params infrastructure is incomplete and needs a bit of plumbing to
>> support port params commands from netlink.
>>
>> Introduce port params registration API, very similar to current devlink
>> params API, add the params xarray to devlink_port structure and
>> decouple devlink params registration routines from the devlink
>> structure.
>>
>> Signed-off-by: Saeed Mahameed <saeedm@...dia.com>
>> Reviewed-by: Jiri Pirko <jiri@...dia.com>
>> ---
>> include/net/devlink.h | 14 ++++
>> net/devlink/param.c | 150 ++++++++++++++++++++++++++++++++++--------
>> net/devlink/port.c | 3 +
>> 3 files changed, 140 insertions(+), 27 deletions(-)
>For me devlink and devlink-port should be really the same, to the point
>that the only difference is `bool is_port` flag inside of the
>struct devlink. Then you could put special logic if really desired (to
>exclude something for port).
Why? Why other devlink objects shouldn't be the same as well. Then we
can have one union. Does not make sense to me. The only think dev and
port is sharing would be params. What else? Totally different beast.
>Then for ease of driver programming you could have also a flag
>"for_port" in the struct devlink_param, so developers will fill that
>out statically and call it on all their devlinks (incl port).
>
>Multiplying the APIs instead of rethinking a problem is not a good long
>term solution.
>
Powered by blists - more mailing lists