> -----Original Message-----
> From: Richardson, Bruce <[email protected]>
> Sent: 10 September 2026 16:00
> To: Mandal, Anurag <[email protected]>
> Cc: [email protected]; Burakov, Anatoly <[email protected]>
> 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 <[email protected]>
> > ---
> > 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.
Thanks,
Anurag M
