On Thu, Jan 4, 2024 at 6:46 PM Dumitrescu, Cristian <cristian.dumitre...@intel.com> wrote: > > > > > -----Original Message----- > > From: jer...@marvell.com <jer...@marvell.com> > > Sent: Tuesday, December 19, 2023 5:30 PM > > To: dev@dpdk.org; Thomas Monjalon <tho...@monjalon.net>; Ferruh Yigit > > <ferruh.yi...@amd.com>; Andrew Rybchenko <andrew.rybche...@oktetlabs.ru> > > Cc: 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; 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>; > > cloud.wangxiao...@huawei.com; yisen.zhu...@huawei.com; Wang, Yong > > <yongw...@vmware.com>; xuanziya...@huawei.com; Dumitrescu, Cristian > > <cristian.dumitre...@intel.com>; Jerin Jacob <jer...@marvell.com> > > Subject: [dpdk-dev] [RFC] ethdev: support Tx queue free descriptor query > > > > From: Jerin Jacob <jer...@marvell.com> > > > > 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> > > --- > > doc/guides/nics/features.rst | 10 ++++ > > doc/guides/nics/features/default.ini | 1 + > > lib/ethdev/ethdev_trace_points.c | 3 ++ > > lib/ethdev/rte_ethdev.h | 78 ++++++++++++++++++++++++++++ > > lib/ethdev/rte_ethdev_core.h | 7 ++- > > lib/ethdev/rte_ethdev_trace_fp.h | 8 +++ > > 6 files changed, 106 insertions(+), 1 deletion(-) > > Hi Jerin,
Hi Cristian, > > 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. > > Regards, > Cristian
