From: Jakub Kicinski <kuba@kernel.org>
To: Jiri Pirko <jiri@resnulli.us>
Cc: Saeed Mahameed <saeed@kernel.org>,
"David S. Miller" <davem@davemloft.net>,
Paolo Abeni <pabeni@redhat.com>,
Eric Dumazet <edumazet@google.com>,
Saeed Mahameed <saeedm@nvidia.com>,
netdev@vger.kernel.org, Tariq Toukan <tariqt@nvidia.com>,
Gal Pressman <gal@nvidia.com>,
Leon Romanovsky <leonro@nvidia.com>, Jiri Pirko <jiri@nvidia.com>
Subject: Re: [PATCH net-next V3 14/15] devlink: Implement devlink param multi attribute nested data values
Date: Tue, 29 Apr 2025 09:58:09 -0700 [thread overview]
Message-ID: <20250429095809.1cbabba4@kernel.org> (raw)
In-Reply-To: <bdk3jo2w7mg5meofpj7c5v6h5ngo46x4zev7buh7iqw3uil3yx@3rljgtc3l464>
On Tue, 29 Apr 2025 13:34:57 +0200 Jiri Pirko wrote:
> >I'd really rather not build any more complexity into this funny
> >indirect attribute construct. Do you have many more arrays to expose?
>
> How else do you imagine to expose arrays in params?
> Btw, why is it "funny"? I mean, if you would be designing it from
> scratch, how would you do that (params with multiple types) differently?
> From netlink perspective there's nothing wrong with it, is it?
The attribute type (nla_type) should define the nested type. Having
the nested type carried as a value in another attribute makes writing
generic parsers so much harder. I made a similar mistake in one the the
ethtool commands.
We should have basically have separate attr types for each of the value
sizes:
DEVLINK_ATTR_PARAM_VALUE_DATA_U32
DEVLINK_ATTR_PARAM_VALUE_DATA_BOOL
etc. They should be in a separate attr space, not the main devlink_attr
one, but every type should have its own value_data attr type.
next prev parent reply other threads:[~2025-04-29 16:58 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-04-25 21:47 [PATCH net-next V3 00/15] devlink, mlx5: Add new parameters for link management and SRIOV/eSwitch configurations Saeed Mahameed
2025-04-25 21:47 ` [PATCH net-next V3 01/15] tools: ynl-gen: allow noncontiguous enums Saeed Mahameed
2025-04-28 23:06 ` Jakub Kicinski
2025-04-29 7:22 ` Jiri Pirko
2025-04-25 21:47 ` [PATCH net-next V3 02/15] devlink: define enum for attr types of dynamic attributes Saeed Mahameed
2025-04-28 23:10 ` Jakub Kicinski
2025-04-29 7:20 ` Jiri Pirko
2025-04-29 11:49 ` Jiri Pirko
2025-04-29 17:01 ` Jakub Kicinski
2025-04-25 21:47 ` [PATCH net-next V3 03/15] devlink: Add 'total_vfs' generic device param Saeed Mahameed
2025-04-25 21:47 ` [PATCH net-next V3 04/15] net/mlx5: Implement cqe_compress_type via devlink params Saeed Mahameed
2025-04-25 21:47 ` [PATCH net-next V3 05/15] net/mlx5: Implement devlink enable_sriov parameter Saeed Mahameed
2025-04-25 21:47 ` [PATCH net-next V3 06/15] net/mlx5: Implement devlink total_vfs parameter Saeed Mahameed
2025-04-25 21:48 ` [PATCH net-next V3 07/15] devlink: pass struct devlink_port * as arg to devlink_nl_param_fill() Saeed Mahameed
2025-04-25 21:48 ` [PATCH net-next V3 08/15] devlink: Implement port params registration Saeed Mahameed
2025-04-25 21:48 ` [PATCH net-next V3 09/15] devlink: Implement get/dump netlink commands for port params Saeed Mahameed
2025-04-25 21:48 ` [PATCH net-next V3 10/15] devlink: Implement set netlink command " Saeed Mahameed
2025-04-25 21:48 ` [PATCH net-next V3 11/15] devlink: Add 'keep_link_up' generic devlink device param Saeed Mahameed
2025-04-25 21:48 ` [PATCH net-next V3 12/15] net/mlx5: Implement devlink keep_link_up port parameter Saeed Mahameed
2025-04-25 21:48 ` [PATCH net-next V3 13/15] devlink: Throw extack messages on param value validation error Saeed Mahameed
2025-04-25 21:48 ` [PATCH net-next V3 14/15] devlink: Implement devlink param multi attribute nested data values Saeed Mahameed
2025-04-28 23:17 ` Jakub Kicinski
2025-04-29 11:34 ` Jiri Pirko
2025-04-29 13:54 ` Przemek Kitszel
2025-04-29 16:33 ` Jiri Pirko
2025-04-29 16:58 ` Jakub Kicinski [this message]
2025-04-30 6:24 ` Jiri Pirko
2025-05-02 11:16 ` Jiri Pirko
2025-04-25 21:48 ` [PATCH net-next V3 15/15] net/mlx5: Implement eSwitch hairpin per prio buffers devlink params Saeed Mahameed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20250429095809.1cbabba4@kernel.org \
--to=kuba@kernel.org \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=gal@nvidia.com \
--cc=jiri@nvidia.com \
--cc=jiri@resnulli.us \
--cc=leonro@nvidia.com \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=saeed@kernel.org \
--cc=saeedm@nvidia.com \
--cc=tariqt@nvidia.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.