Thread (16 messages) 16 messages, 5 authors, 2025-05-27

Re: [PATCH net-next V10 1/6] devlink: Extend devlink rate API with traffic classes bandwidth management

flat view

From: Carolina Jubran <hidden>
Date: 2025-05-25 14:57:41
Also in: linux-doc, linux-kselftest, linux-rdma, lkml


On 21/05/2025 1:53, Jakub Kicinski wrote:
A few quick comments here as the test is failing

On Tue, 20 May 2025 21:38:02 +0300 Tariq Toukan wrote:
quoted
+      -
+        name: rate-tc-bws
+        type: nest
+        multi-attr: true
+        nested-attributes: dl-rate-tc-bws
+      -
+        name: rate-tc-index
+        type: u8
+        checks:
+          min: 0
+          max: rate-tc-index-max
no need for min: 0 on an unsigned type ?
Will remove them.
quoted
+      -
+        name: rate-tc-bw
+        type: u32
+        doc: |
+             Specifies the bandwidth allocation for the Traffic Class as a
+             percentage.
+        checks:
+          min: 0
+          max: 100
Why in percentage? I don't think any existing param in devlink rate
or net shapers is in percentage right? Not according to what i can
grok about the uAPI.
I thought percentage might fit better here because it lets users clearly set the bandwidth share for each traffic class. While this isn’t the same as tx_weight in devlink-rate, the idea is related since both use relative values. If there isn’t a strong reason against it, I’d like to keep using percentages here.
quoted
+static int devlink_nl_rate_tc_bw_parse(struct nlattr *parent_nest, u32 *tc_bw,
+				       unsigned long *bitmap, struct netlink_ext_ack *extack)
+{
+	struct nlattr *tb[DEVLINK_ATTR_MAX + 1];
+	u8 tc_index;
+
+	nla_parse_nested(tb, DEVLINK_ATTR_MAX, parent_nest, devlink_dl_rate_tc_bws_nl_policy,
Let's error check this, I get that we already validated via the policy
but what if we do memory allocations during parsing one day, or some
other failure-prone operation.. better check the return value.
Ack. will do.
nit: over 80 chars for no good reason, the line overflows anyway.
Please use checkpatch --max-line-width=80 for core code,
at the very least.
I noticed the current code already goes over 80 chars, but I’ll update it to follow the 80-char limit. Will fix, thanks.
quoted
+			 extack);
+	if (!tb[DEVLINK_ATTR_RATE_TC_INDEX]) {
+		NL_SET_ERR_ATTR_MISS(extack, parent_nest, DEVLINK_ATTR_RATE_TC_INDEX);
+		return -EINVAL;
+	}
+
+	tc_index = nla_get_u8(tb[DEVLINK_ATTR_RATE_TC_INDEX]);
+
+	if (!tb[DEVLINK_ATTR_RATE_TC_BW]) {
+		NL_SET_ERR_ATTR_MISS(extack, parent_nest, DEVLINK_ATTR_RATE_TC_BW);
+		return -EINVAL;
+	}
+
+	if (test_and_set_bit(tc_index, bitmap)) {
+		NL_SET_ERR_MSG_FMT(extack, "Duplicate traffic class index specified (%u)",
+				   tc_index);
+		return -EINVAL;
+	}
+
+	tc_bw[tc_index] = nla_get_u32(tb[DEVLINK_ATTR_RATE_TC_BW]);
+
+	return 0;
+}
+
+static int devlink_nl_rate_tc_bw_set(struct devlink_rate *devlink_rate,
+				     struct genl_info *info)
+{
+	DECLARE_BITMAP(bitmap, DEVLINK_RATE_TCS_MAX) = {};
+	struct devlink *devlink = devlink_rate->devlink;
+	const struct devlink_ops *ops = devlink->ops;
+	int rem, err = -EOPNOTSUPP, i, total = 0;
+	u32 tc_bw[DEVLINK_RATE_TCS_MAX] = {};
+	struct nlattr *attr;
+
+	nla_for_each_attr(attr, genlmsg_data(info->genlhdr),
+			  genlmsg_len(info->genlhdr), rem) {
  nla_for_each_attr_type() ?
  or better still add a _type() version of nlmsg_for_each_attr() ?
Good point, thanks. I’ll add a _type() version for nlmsg_for_each_attr. Do you prefer this to be part of this patch or should I send it as a separate patch?
quoted
+		if (nla_type(attr) == DEVLINK_ATTR_RATE_TC_BWS) {
+			err = devlink_nl_rate_tc_bw_parse(attr, tc_bw, bitmap, info->extack);
+			if (err)
+				return err;
+		}
+	}
  
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help