> -----Original Message----- > From: Thomas Monjalon <tho...@monjalon.net> > Sent: Friday, January 5, 2024 10:04 AM > To: Jerin Jacob <jerinjac...@gmail.com> > Cc: Dumitrescu, Cristian <cristian.dumitre...@intel.com>; Konstantin Ananyev > <konstantin.anan...@huawei.com>; > jer...@marvell.com; dev@dpdk.org; Ferruh Yigit <ferruh.yi...@amd.com>; Andrew > Rybchenko <andrew.rybche...@oktetlabs.ru>; > ferruh.yi...@xilinx.com; ajit.khapa...@broadcom.com; abo...@pensando.io; > Xing, Beilei <beilei.x...@intel.com>; Richardson, Bruce > <bruce.richard...@intel.com>; ch...@att.com; chenbo....@intel.com; Loftus, > Ciara <ciara.lof...@intel.com>; > dsinghra...@marvell.com; Czeck, Ed <ed.cz...@atomicrules.com>; > evge...@amazon.com; gr...@u256.net; g.si...@nxp.com; > zhouguoy...@huawei.com; Wang, Haiyue <haiyue.w...@intel.com>; > hka...@marvell.com; heinrich.k...@corigine.com; > hemant.agra...@nxp.com; hyon...@cisco.com; igo...@amazon.com; > irussk...@marvell.com; jgraj...@cisco.com; Singh, Jasvinder > <jasvinder.si...@intel.com>; jianw...@trustnetic.com; > jiawe...@trustnetic.com; Wu, Jingjing <jingjing...@intel.com>; > johnd...@cisco.com; john.mil...@atomicrules.com; linvi...@tuxdriver.com; > Wiles, Keith <keith.wi...@intel.com>; > kirankum...@marvell.com; ouli...@huawei.com; lir...@marvell.com; > lon...@microsoft.com; m...@semihalf.com; > spin...@cesnet.cz; ma...@nvidia.com; Peters, Matt > <matt.pet...@windriver.com>; maxime.coque...@redhat.com; > m...@semihalf.com; humin (Q) <humi...@huawei.com>; pna...@marvell.com; > ndabilpu...@marvell.com; Yang, Qiming > <qiming.y...@intel.com>; Zhang, Qi Z <qi.z.zh...@intel.com>; > rad...@marvell.com; rahul.lakkire...@chelsio.com; > rm...@marvell.com; Xu, Rosen <rosen...@intel.com>; sachin.sax...@oss.nxp.com; > skotesh...@marvell.com; > shsha...@marvell.com; shaib...@amazon.com; Siegel, Shepard > <shepard.sie...@atomicrules.com>; asoma...@amd.com; > somnath.ko...@broadcom.com; sthem...@microsoft.com; Webster, Steven > <steven.webs...@windriver.com>; > sk...@marvell.com; mtetsu...@gmail.com; vbu...@marvell.com; > viachesl...@nvidia.com; Wang, Xiao W > <xiao.w.w...@intel.com>; Wangxiaoyun (Cloud) <cloud.wangxiao...@huawei.com>; > Zhuangyuzeng (Yisen) > <yisen.zhu...@huawei.com>; Wang, Yong <yongw...@vmware.com>; Xuanziyang > (William) <william.xuanziy...@huawei.com> > 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 <tho...@monjalon.net> 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 <jer...@marvell.com> > > > > > > > > > > > > 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.
