> -----Original Message----- > From: Richardson, Bruce <[email protected]> > Sent: 15 September 2026 22:43 > 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 Tue, Sep 15, 2026 at 11:19:08AM +0100, Mandal, Anurag wrote: > > > -----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. > > > 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
Hi Bruce, Thank you for the review as well as feedback. I have addressed them in v2. Kindly check. Thank you. Regards, Anurag M
