From: Jakub Kicinski <kuba@kernel.org>
To: Ratheesh Kannoth <rkannoth@marvell.com>
Cc: <linux-kernel@vger.kernel.org>, <linux-rdma@vger.kernel.org>,
<netdev@vger.kernel.org>, <oss-drivers@corigine.com>,
<akiyano@amazon.com>, <andrew+netdev@lunn.ch>,
<anthony.l.nguyen@intel.com>, <arkadiusz.kubalewski@intel.com>,
<brett.creeley@amd.com>, <darinzon@amazon.com>,
<davem@davemloft.net>, <donald.hunter@gmail.com>,
<edumazet@google.com>, <horms@kernel.org>, <idosch@nvidia.com>,
<ivecera@redhat.com>, <jiri@resnulli.us>, <leon@kernel.org>,
<mbloch@nvidia.com>, <michael.chan@broadcom.com>,
<pabeni@redhat.com>, <pavan.chebbi@broadcom.com>,
<petrm@nvidia.com>, <Prathosh.Satish@microchip.com>,
<przemyslaw.kitszel@intel.com>, <saeedm@nvidia.com>,
<sgoutham@marvell.com>, <tariqt@nvidia.com>,
<vadim.fedorenko@linux.dev>
Subject: Re: [PATCH v16 net-next 4/9] devlink: Implement devlink param multi attribute nested data values
Date: Mon, 25 May 2026 14:09:50 -0700 [thread overview]
Message-ID: <20260525140950.7e5cac5e@kernel.org> (raw)
In-Reply-To: <20260521095303.2395584-5-rkannoth@marvell.com>
On Thu, 21 May 2026 15:22:58 +0530 Ratheesh Kannoth wrote:
> From: Saeed Mahameed <saeedm@nvidia.com>
>
> Devlink param value attribute is not defined since devlink is handling
> the value validating and parsing internally, this allows us to implement
> multi attribute values without breaking any policies.
>
> Devlink param multi-attribute values are considered to be dynamically
> sized arrays of u64 values, by introducing a new devlink param type
> DEVLINK_PARAM_TYPE_U64_ARRAY, driver and user space can set a variable
> count of u64 values into the DEVLINK_ATTR_PARAM_VALUE_DATA attribute.
>
> Implement get/set parsing and add to the internal value structure passed
> to drivers.
>
> This is useful for devices that need to configure a list of values for
> a specific configuration.
> diff --git a/net/devlink/param.c b/net/devlink/param.c
> index 1a196d3a843d..6e0e48696f4a 100644
> --- a/net/devlink/param.c
> +++ b/net/devlink/param.c
> @@ -252,6 +252,15 @@ devlink_nl_param_value_put(struct sk_buff *msg, enum devlink_param_type type,
> return -EMSGSIZE;
> }
> break;
> + case DEVLINK_PARAM_TYPE_U64_ARRAY:
> + for (int i = 0; i < val->u64arr.size; i++) {
> + if (i >= __DEVLINK_PARAM_MAX_ARRAY_SIZE)
> + break;
Why not check this before the loop and return an error if someone tries
to dump too much data?
> + if (nla_put_uint(msg, nla_type, val->u64arr.val[i]))
> + return -EMSGSIZE;
> + }
> + break;
> }
> return 0;
> }
> @@ -304,56 +313,78 @@ static int devlink_nl_param_fill(struct sk_buff *msg, struct devlink *devlink,
> u32 portid, u32 seq, int flags,
> struct netlink_ext_ack *extack)
> {
> - union devlink_param_value default_value[DEVLINK_PARAM_CMODE_MAX + 1];
> - union devlink_param_value param_value[DEVLINK_PARAM_CMODE_MAX + 1];
> bool default_value_set[DEVLINK_PARAM_CMODE_MAX + 1] = {};
> bool param_value_set[DEVLINK_PARAM_CMODE_MAX + 1] = {};
> const struct devlink_param *param = param_item->param;
> - struct devlink_param_gset_ctx ctx;
> + union devlink_param_value *default_value;
> + union devlink_param_value *param_value;
> + struct devlink_param_gset_ctx *ctx;
> struct nlattr *param_values_list;
> struct nlattr *param_attr;
> void *hdr;
> int err;
> int i;
>
> + default_value = kcalloc(DEVLINK_PARAM_CMODE_MAX + 1,
> + sizeof(*default_value), GFP_KERNEL);
> + if (!default_value)
> + return -ENOMEM;
> +
> + param_value = kcalloc(DEVLINK_PARAM_CMODE_MAX + 1,
> + sizeof(*param_value), GFP_KERNEL);
> + if (!param_value) {
> + kfree(default_value);
> + return -ENOMEM;
> + }
> +
> + ctx = kzalloc_obj(*ctx);
> + if (!ctx) {
> + kfree(param_value);
> + kfree(default_value);
> + return -ENOMEM;
> + }
The mem alloc should preferably be a separate patch for ease of review.
> static void devlink_param_notify(struct devlink *devlink,
> @@ -507,7 +545,7 @@ devlink_param_value_get_from_info(const struct devlink_param *param,
> union devlink_param_value *value)
> {
> struct nlattr *param_data;
> - int len;
> + int len, cnt, rem;
>
> param_data = info->attrs[DEVLINK_ATTR_PARAM_VALUE_DATA];
>
> @@ -547,6 +585,26 @@ devlink_param_value_get_from_info(const struct devlink_param *param,
> return -EINVAL;
> value->vbool = nla_get_flag(param_data);
> break;
> +
> + case DEVLINK_PARAM_TYPE_U64_ARRAY:
> + cnt = 0;
> + nla_for_each_attr_type(param_data,
> + DEVLINK_ATTR_PARAM_VALUE_DATA,
> + genlmsg_data(info->genlhdr),
> + genlmsg_len(info->genlhdr), rem) {
> + if (cnt >= __DEVLINK_PARAM_MAX_ARRAY_SIZE)
> + return -EMSGSIZE;
> +
> + if ((nla_len(param_data) != sizeof(u64)) &&
> + (nla_len(param_data) != sizeof(u32)))
NL_SET_BAD_ATTR() would be good here
> + return -EINVAL;
> +
> + value->u64arr.val[cnt] = (u64)nla_get_uint(param_data);
Why the cast? Looks like a leftover..
> + cnt++;
> + }
> +
> + value->u64arr.size = cnt;
> + break;
> }
> return 0;
> }
next prev parent reply other threads:[~2026-05-25 21:09 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-21 9:52 [PATCH v16 net-next 0/9] octeontx2-af: npc: Enhancements Ratheesh Kannoth
2026-05-21 9:52 ` [PATCH v16 net-next 1/9] octeontx2-af: npc: cn20k: debugfs enhancements Ratheesh Kannoth
2026-05-22 11:38 ` Ratheesh Kannoth
2026-05-25 20:59 ` Jakub Kicinski
2026-06-01 2:24 ` Ratheesh Kannoth
2026-05-21 9:52 ` [PATCH v16 net-next 2/9] net/mlx5e: Reduce stack use reading PCIe congestion thresholds Ratheesh Kannoth
2026-05-21 9:52 ` [PATCH v16 net-next 3/9] devlink: pass param values by pointer Ratheesh Kannoth
2026-05-21 9:52 ` [PATCH v16 net-next 4/9] devlink: Implement devlink param multi attribute nested data values Ratheesh Kannoth
2026-05-25 21:09 ` Jakub Kicinski [this message]
2026-05-21 9:52 ` [PATCH v16 net-next 5/9] octeontx2-af: npc: cn20k: add subbank search order control Ratheesh Kannoth
2026-05-21 9:53 ` [PATCH v16 net-next 6/9] octeontx2: cn20k: Coordinate default rules with NIX LF lifecycle Ratheesh Kannoth
2026-05-21 9:53 ` [PATCH v16 net-next 7/9] octeontx2-af: npc: Support for custom KPU profile from filesystem Ratheesh Kannoth
2026-05-22 11:48 ` Ratheesh Kannoth
2026-05-21 9:53 ` [PATCH v16 net-next 8/9] octeontx2: cn20k: Respect NPC MCAM X2/X4 profile in flows and DFT alloc Ratheesh Kannoth
2026-05-22 11:51 ` Ratheesh Kannoth
2026-05-21 9:53 ` [PATCH v16 net-next 9/9] octeontx2-af: npc: cn20k: Allocate npc_priv and dstats dynamically Ratheesh Kannoth
2026-05-25 21:20 ` [PATCH v16 net-next 0/9] octeontx2-af: npc: Enhancements patchwork-bot+netdevbpf
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=20260525140950.7e5cac5e@kernel.org \
--to=kuba@kernel.org \
--cc=Prathosh.Satish@microchip.com \
--cc=akiyano@amazon.com \
--cc=andrew+netdev@lunn.ch \
--cc=anthony.l.nguyen@intel.com \
--cc=arkadiusz.kubalewski@intel.com \
--cc=brett.creeley@amd.com \
--cc=darinzon@amazon.com \
--cc=davem@davemloft.net \
--cc=donald.hunter@gmail.com \
--cc=edumazet@google.com \
--cc=horms@kernel.org \
--cc=idosch@nvidia.com \
--cc=ivecera@redhat.com \
--cc=jiri@resnulli.us \
--cc=leon@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-rdma@vger.kernel.org \
--cc=mbloch@nvidia.com \
--cc=michael.chan@broadcom.com \
--cc=netdev@vger.kernel.org \
--cc=oss-drivers@corigine.com \
--cc=pabeni@redhat.com \
--cc=pavan.chebbi@broadcom.com \
--cc=petrm@nvidia.com \
--cc=przemyslaw.kitszel@intel.com \
--cc=rkannoth@marvell.com \
--cc=saeedm@nvidia.com \
--cc=sgoutham@marvell.com \
--cc=tariqt@nvidia.com \
--cc=vadim.fedorenko@linux.dev \
/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.