Re: [PATCH] net/ice: add per-queue Tx rate limit support

[Bruce Richardson <bruce.richardson@intel.com>]

On Tue, Sep 15, 2026 at 11:19:08AM +0100, Mandal, Anurag wrote:
> > -----Original Message-----
> > From: Richardson, Bruce <bruce.richardson@intel.com>
> > Sent: 10 September 2026 16:00
> > To: Mandal, Anurag <anurag.mandal@intel.com>
> > Cc: dev@dpdk.org; Burakov, Anatoly <anatoly.burakov@intel.com>
> > Subject: Re: [PATCH] net/ice: add per-queue Tx rate limit support
> > 
> > On Thu, Sep 10, 2026 at 10:04:32AM +0000, Anurag Mandal wrote:
> > > The Tx rate can be limited per queue with ethdev operation
> > > ``rte_eth_set_queue_rate_limit()``
> > > and can be read through ``rte_eth_get_queue_rate_limit()``.
> > >
> > > This feature uses the hardware packet pacing mechanism to enforce a
> > > data rate on individual Tx queues without tearing down the queue.
> > >
> > > The rate is specified in Mbps.
> > >
> > > ice_set_queue_rate_limit() applies the requested rate as the EIR
> > > (maximum bandwidth) limit of the queue scheduler node using
> > > ice_cfg_q_bw_lmt(), converting the Mbps value taken by the API to the
> > > Kbps expected by the scheduler.
> > > A rate of 0 removes the limit and restores the default bandwidth via
> > > ice_cfg_q_bw_dflt_lmt().
> > >
> > > ice_get_queue_rate_limit() reads back the value cached in the queue
> > > context by the scheduler on a successful set, and reports 0 when the
> > > queue runs unlimited.
> > >
> > > Signed-off-by: Anurag Mandal <anurag.mandal@intel.com>
> > > ---
> > >  doc/guides/nics/features/ice.ini       |  1 +
> > >  doc/guides/rel_notes/release_26_11.rst |  3 +
> > >  drivers/net/intel/ice/ice_ethdev.c     | 77 ++++++++++++++++++++++++++
> > >  3 files changed, 81 insertions(+)
> > >
> > Is this functionality not overlapping with what the rte_rm APIs provide for
> > ice? Using the rte_rm hierarchies, it's possible to rate limit a queue, no?
> > 
> > /Bruce
> 
> Hi Bruce,
> 
> I am guessing you meant rte_tm APIs instead of rte_rm.
> Yes, the two paths ultimately program the same hardware field.
> But, there are few reasons I still think the ethdev op is worth having:
> 1. rte_tm commit bounces the port. This does not. 
>     So adjusting one queue's rate through rte_tm drops traffic on every queue and bounces the link.
> 2. VSI subtree is rebuilt for rte_tm :
>  	a. Stop the port if running
> 	b. Walk the VSI root up or down to the new layer, freeing sibling subtrees
> 	c. free_sched_node_recursive() - tear down the existing scheduler subtree
> 	d. create_sched_node_recursive() - rebuild it, ice_sched_add_elems() per node
> 	e. Recompute pf->main_vsi->nb_qps, then ice_alloc_lan_q_ctx() to resize queue contexts
> 	f. Restart the port
> 3. ixgbe & txgbe pmds also implement both.
> 
Yes, your logic makes sense.

However, one final concern, it appears that this feature doesn't interact
in any way with the rte_tm one. Therefore, if a user configures a full
hierarchy using rte_tm, and then uses this new API to tweak the Tx rates on
queues, we could see problems later, e.g. losing all adjustments on apply
of a slightly different hierarchy etc.

If the two features don't interact well, we may need to put in place some
form of locking to ensure that you can't use one when you use the other.
What do you think?

/Bruce