> -----Original Message----- > From: Thomas Monjalon <[email protected]> > Sent: Friday, January 5, 2024 10:04 AM > To: Jerin Jacob <[email protected]> > Cc: Dumitrescu, Cristian <[email protected]>; Konstantin Ananyev > <[email protected]>; > [email protected]; [email protected]; Ferruh Yigit <[email protected]>; Andrew > Rybchenko <[email protected]>; > [email protected]; [email protected]; [email protected]; > Xing, Beilei <[email protected]>; Richardson, Bruce > <[email protected]>; [email protected]; [email protected]; Loftus, > Ciara <[email protected]>; > [email protected]; Czeck, Ed <[email protected]>; > [email protected]; [email protected]; [email protected]; > [email protected]; Wang, Haiyue <[email protected]>; > [email protected]; [email protected]; > [email protected]; [email protected]; [email protected]; > [email protected]; [email protected]; Singh, Jasvinder > <[email protected]>; [email protected]; > [email protected]; Wu, Jingjing <[email protected]>; > [email protected]; [email protected]; [email protected]; > Wiles, Keith <[email protected]>; > [email protected]; [email protected]; [email protected]; > [email protected]; [email protected]; > [email protected]; [email protected]; Peters, Matt > <[email protected]>; [email protected]; > [email protected]; humin (Q) <[email protected]>; [email protected]; > [email protected]; Yang, Qiming > <[email protected]>; Zhang, Qi Z <[email protected]>; > [email protected]; [email protected]; > [email protected]; Xu, Rosen <[email protected]>; [email protected]; > [email protected]; > [email protected]; [email protected]; Siegel, Shepard > <[email protected]>; [email protected]; > [email protected]; [email protected]; Webster, Steven > <[email protected]>; > [email protected]; [email protected]; [email protected]; > [email protected]; Wang, Xiao W > <[email protected]>; Wangxiaoyun (Cloud) <[email protected]>; > Zhuangyuzeng (Yisen) > <[email protected]>; Wang, Yong <[email protected]>; Xuanziyang > (William) <[email protected]> > Subject: Re: [dpdk-dev] [RFC] ethdev: support Tx queue free descriptor query > > 05/01/2024 10:57, Jerin Jacob: > > On Thu, Jan 4, 2024 at 11:59 PM Thomas Monjalon <[email protected]> wrote: > > > > > > 04/01/2024 15:21, Konstantin Ananyev: > > > > > > > > > > > Introduce a new API to retrieve the number of available free > > > > > > > descriptors > > > > > > > in a Tx queue. Applications can leverage this API in the fast > > > > > > > path to > > > > > > > inspect the Tx queue occupancy and take appropriate actions based > > > > > > > on the > > > > > > > available free descriptors. > > > > > > > > > > > > > > A notable use case could be implementing Random Early Discard > > > > > > > (RED) > > > > > > > in software based on Tx queue occupancy. > > > > > > > > > > > > > > Signed-off-by: Jerin Jacob <[email protected]> > > > > > > > > > > > > I think having an API to get the number of free descriptors per > > > > > > queue is a good idea. Why have it only for TX queues and not > for RX > > > > > queues as well? > > > > > > > > > > I see no harm in adding for Rx as well. I think, it is better to have > > > > > separate API for each instead of adding argument as it is fast path > > > > > API. > > > > > If so, we could add a new API when there is any PMD implementation or > > > > > need for this. > > > > > > > > I think for RX we already have similar one: > > > > /** @internal Get number of used descriptors on a receive queue. */ > > > > typedef uint32_t (*eth_rx_queue_count_t)(void *rxq); > > > > > > rte_eth_rx_queue_count() gives the number of Rx used descriptors > > > rte_eth_rx_descriptor_status() gives the status of one Rx descriptor > > > rte_eth_tx_descriptor_status() gives the status of one Tx descriptor > > > > > > This patch is adding a function to get Tx available descriptors, > > > rte_eth_tx_queue_free_desc_get(). > > > I can see a symmetry with rte_eth_rx_queue_count(). > > > For consistency I would rename it to rte_eth_tx_queue_free_count(). > > > > > > Should we add rte_eth_tx_queue_count() and rte_eth_rx_queue_free_count()? > > > > IMO, rte_eth_rx_queue_free_count() is enough as > > used count = total desc number(configured via nb_tx_desc with > > rte_eth_tx_queue_setup()) - free count > > I'm fine with that. >
Yep, agree. If we ever need rte_eth_rx_queue_free_count() and rte_eth_tx_queue_used_count(), it could be done via slow-path as Jerin outlined above, no need to waste entries in fp_ops for that.
