DPDK-dev Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Bruce Richardson <bruce.richardson@intel.com>
To: Ciara Loftus <ciara.loftus@intel.com>
Cc: <dev@dpdk.org>, <stable@dpdk.org>
Subject: Re: [PATCH] net/ice: fix TM node ID validation against configured queues
Date: Tue, 19 May 2026 15:58:26 +0100	[thread overview]
Message-ID: <agx6kiQyvHZJ96ob@bricha3-mobl1.ger.corp.intel.com> (raw)
In-Reply-To: <20260505123157.1387791-1-ciara.loftus@intel.com>

On Tue, May 05, 2026 at 12:31:57PM +0000, Ciara Loftus wrote:
> The leaf node ID boundary is checked against the compile-time constant
> `RTE_MAX_QUEUES_PER_PORT` (1024) rather than the number of Tx queues
> configured for the port. The rte_tm specification reserves IDs 0 to
> (N-1) for leaf nodes, where N is the configured queue count, so using
> the constant produces wrong results whenever N is less than 1024. Fix by
> replacing the constant with the runtime queue count.
> 
> Also add an explicit check in the non-leaf validation path that rejects
> IDs in the leaf-reserved range. This condition can be triggered
> two ways: adding a leaf node before its parent chain is complete (the
> node resolves to a non-leaf level), or assigning a leaf-range ID to a
> node intended as non-leaf.
> 
> Fixes: 715d449a965b ("net/ice: enhance Tx scheduler hierarchy support")

I think this fix will cause other issues when we want to use large numbers
of queues. From the commit log for 715d449a965b:

    "If the HW/firmware allows it, allow creating up to 2k child
    nodes per scheduler node. Also expand the number of supported layers to
    the max available, rather than always just having 3 layers.  One
    restriction on this change is that the topology needs to be configured
    and enabled before port queue setup"

The last part is significant - the number of configured queues must be
supported by a scheduler hierarchy with enough nodes at the next,
queue-group level. Therefore, before configuring large numbers of queues we
need to configure a non-default hierarchy. Therefore, when running this
check the value of nb_txq is not known, which is why the original patch
changed the check to RTE_MAX_QUEUES_PER_PORT.

However, you correctly point out in this fix, that that is not according to
the spec for rte_tm. Therefore, I suggest changing the check, if possible:

* if nb_txq == 0 (i.e. no queues configured yet), then keep as-is with
  MAX_QUEUES
* for cases where nb_txq != 0, then use nb_txq.

Does that seem sensible, or any better alternatives you can see?

/Bruce


> Cc: stable@dpdk.org
> 
> Signed-off-by: Ciara Loftus <ciara.loftus@intel.com>
> ---
>  drivers/net/intel/ice/ice_tm.c | 14 +++++++++++---
>  1 file changed, 11 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/net/intel/ice/ice_tm.c b/drivers/net/intel/ice/ice_tm.c
> index ff53f2acfd..7ee4070007 100644
> --- a/drivers/net/intel/ice/ice_tm.c
> +++ b/drivers/net/intel/ice/ice_tm.c
> @@ -88,6 +88,7 @@ ice_node_param_check(uint32_t node_id,
>  		      uint32_t priority, uint32_t weight,
>  		      const struct rte_tm_node_params *params,
>  		      bool is_leaf,
> +		      uint16_t nb_txq,
>  		      struct rte_tm_error *error)
>  {
>  	/* checked all the unsupported parameter */
> @@ -123,6 +124,11 @@ ice_node_param_check(uint32_t node_id,
>  
>  	/* for non-leaf node */
>  	if (!is_leaf) {
> +		if (node_id < nb_txq) {
> +			error->type = RTE_TM_ERROR_TYPE_NODE_ID;
> +			error->message = "node ID is reserved for leaf nodes";
> +			return -EINVAL;
> +		}
>  		if (params->nonleaf.wfq_weight_mode) {
>  			error->type =
>  				RTE_TM_ERROR_TYPE_NODE_PARAMS_WFQ_WEIGHT_MODE;
> @@ -146,7 +152,7 @@ ice_node_param_check(uint32_t node_id,
>  	}
>  
>  	/* for leaf node */
> -	if (node_id >= RTE_MAX_QUEUES_PER_PORT) {
> +	if (node_id >= nb_txq) {
>  		error->type = RTE_TM_ERROR_TYPE_NODE_ID;
>  		error->message = "Node ID out of range for a leaf node.";
>  		return -EINVAL;
> @@ -440,7 +446,8 @@ ice_tm_node_add(struct rte_eth_dev *dev, uint32_t node_id,
>  			return -EINVAL;
>  		}
>  
> -		ret = ice_node_param_check(node_id, priority, weight, params, false, error);
> +		ret = ice_node_param_check(node_id, priority, weight, params, false,
> +				dev->data->nb_tx_queues, error);
>  		if (ret)
>  			return ret;
>  
> @@ -479,7 +486,8 @@ ice_tm_node_add(struct rte_eth_dev *dev, uint32_t node_id,
>  	}
>  
>  	ret = ice_node_param_check(node_id, priority, weight,
> -			params, level_id == ice_get_leaf_level(pf), error);
> +			params, level_id == ice_get_leaf_level(pf),
> +			dev->data->nb_tx_queues, error);
>  	if (ret)
>  		return ret;
>  
> -- 
> 2.43.0
> 

  reply	other threads:[~2026-05-19 14:58 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-05-05 12:31 [PATCH] net/ice: fix TM node ID validation against configured queues Ciara Loftus
2026-05-19 14:58 ` Bruce Richardson [this message]
2026-05-20 15:03   ` Loftus, Ciara
2026-05-20 15:07 ` [PATCH v2] " Ciara Loftus
2026-05-20 15:24   ` Bruce Richardson
2026-05-22 14:57     ` Bruce Richardson

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=agx6kiQyvHZJ96ob@bricha3-mobl1.ger.corp.intel.com \
    --to=bruce.richardson@intel.com \
    --cc=ciara.loftus@intel.com \
    --cc=dev@dpdk.org \
    --cc=stable@dpdk.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox