From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 4876943873; Tue, 9 Jan 2024 15:45:58 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id DD9344021F; Tue, 9 Jan 2024 15:45:57 +0100 (CET) Received: from mail-qt1-f178.google.com (mail-qt1-f178.google.com [209.85.160.178]) by mails.dpdk.org (Postfix) with ESMTP id 25C1C4013F for ; Tue, 9 Jan 2024 15:45:57 +0100 (CET) Received: by mail-qt1-f178.google.com with SMTP id d75a77b69052e-4299400fd94so12338571cf.2 for ; Tue, 09 Jan 2024 06:45:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1704811556; x=1705416356; darn=dpdk.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=pdDsg4UgGVbebfAJqKFCS8r94yad7aOVw7sTTD/1nCs=; b=jW6Kbmaw7Ig+8tiAlCSCR1U/8IoIOd7uGBmUZd/jyRxQvwefUHVp01cVfQp4qYUbo4 O5IZdaypbbD7fCcbBSbC+WTwBI7ic8Gu+dUrtp0cWV9vZr68sGsa5a8u/a78DO9DDdv+ HxAMu/9wI20EATLr4fd3ubJadlNGSXYjaosMo7AP4i3s1gqcR1ZSa3su3EqtqxnvQKHu B/KHjAGCMSgotMklnvp42d4KOBb1ySWZJS30e8xAZtRDoEUqHFGBMIdmR8b3Ct9b8J8y SBQKjlRYqKGEbZy+zCrN9zKAlwdqw+zUpOy9pf/ZP0CVxSrlOEkIDV7PbYBu8Ov6J3qt 1QVQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1704811556; x=1705416356; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=pdDsg4UgGVbebfAJqKFCS8r94yad7aOVw7sTTD/1nCs=; b=vhJgYpN91JhaDwth7iXQs8E7IKU03F1FM9dhFlqHyTldpHnKWNk6UjLJsl9UkiJ8St rlsQj04MkDqSED6MA2NojhgIHLJzLwx89Pwqj2g3BolllFyL3DPzVuAJO7sMq3mA1+xh 3S24Zw2zqgRc4HForEmCoNqamHMVSRiJZqbeoPTOd/rfQefyjr1kpVMrWxe5DrVsDrJz uwb0NXBhaHovFwGU/mLzw8u0BHJYWV9bHeLTOlytuiKNGD6UGHVKUmBuA8irNORN0V+A PHbhdX66aEmXTSOCrULLBfhkE85Wqvyy+Lssg5L9yI3qbngUlQnK45UAOvdiToHLzLS+ BgJA== X-Gm-Message-State: AOJu0YxSJ2uVM+C2gTGVbeu0J1L6KcRFSernvTdpaWYLsFNha++99QRB Hm+EWxu1voVISgc8JwbxvVda31kdIN3pxZgzlfk= X-Google-Smtp-Source: AGHT+IFkgEgGkQf+cSCKFrjHMkP8plTPLhjTUEVA04KvZhBnjbS6JN13Jdfz7jYTw72znSSyHVaKOCQOwiDEaaI6I2g= X-Received: by 2002:a05:622a:295:b0:429:ae9c:6e04 with SMTP id z21-20020a05622a029500b00429ae9c6e04mr338106qtw.91.1704811556385; Tue, 09 Jan 2024 06:45:56 -0800 (PST) MIME-Version: 1.0 References: <20231219172948.3909749-1-jerinj@marvell.com> <852198449.0ifERbkFSE@thomas> <9265280.rMLUfLXkoz@thomas> <94b394799dd84797b9ddb83b007f9972@huawei.com> <98CBD80474FA8B44BF855DF32C47DC35E9F11D@smartserver.smartshare.dk> In-Reply-To: <98CBD80474FA8B44BF855DF32C47DC35E9F11D@smartserver.smartshare.dk> From: Jerin Jacob Date: Tue, 9 Jan 2024 20:15:29 +0530 Message-ID: Subject: Re: [dpdk-dev] [RFC] ethdev: support Tx queue free descriptor query To: =?UTF-8?Q?Morten_Br=C3=B8rup?= Cc: Konstantin Ananyev , Thomas Monjalon , "Dumitrescu, Cristian" , jerinj@marvell.com, dev@dpdk.org, Ferruh Yigit , Andrew Rybchenko , ferruh.yigit@xilinx.com, ajit.khaparde@broadcom.com, aboyer@pensando.io, "Xing, Beilei" , "Richardson, Bruce" , chas3@att.com, chenbo.xia@intel.com, "Loftus, Ciara" , dsinghrawat@marvell.com, "Czeck, Ed" , evgenys@amazon.com, grive@u256.net, g.singh@nxp.com, "Wang, Haiyue" , hkalra@marvell.com, heinrich.kuhn@corigine.com, hemant.agrawal@nxp.com, hyonkim@cisco.com, igorch@amazon.com, irusskikh@marvell.com, jgrajcia@cisco.com, "Singh, Jasvinder" , jianwang@trustnetic.com, jiawenwu@trustnetic.com, "Wu, Jingjing" , johndale@cisco.com, john.miller@atomicrules.com, linville@tuxdriver.com, "Wiles, Keith" , kirankumark@marvell.com, lironh@marvell.com, longli@microsoft.com, mw@semihalf.com, spinler@cesnet.cz, matan@nvidia.com, "Peters, Matt" , maxime.coquelin@redhat.com, mk@semihalf.com, "humin (Q)" , pnalla@marvell.com, ndabilpuram@marvell.com, "Yang, Qiming" , "Zhang, Qi Z" , radhac@marvell.com, rahul.lakkireddy@chelsio.com, rmody@marvell.com, "Xu, Rosen" , sachin.saxena@oss.nxp.com, skoteshwar@marvell.com, shshaikh@marvell.com, shaibran@amazon.com, "Siegel, Shepard" , asomalap@amd.com, somnath.kotur@broadcom.com, sthemmin@microsoft.com, "Webster, Steven" , skori@marvell.com, mtetsuyah@gmail.com, vburru@marvell.com, viacheslavo@nvidia.com, "Wang, Xiao W" , "Wangxiaoyun (Cloud)" , "Zhuangyuzeng (Yisen)" , "Wang, Yong" , "Xuanziyang (William)" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org On Tue, Jan 9, 2024 at 2:24=E2=80=AFAM Morten Br=C3=B8rup wrote: > > > From: Konstantin Ananyev [mailto:konstantin.ananyev@huawei.com] > > Sent: Friday, 5 January 2024 12.13 > > > > > From: Thomas Monjalon > > > Sent: Friday, January 5, 2024 10:04 AM > > > > > > 05/01/2024 10:57, Jerin Jacob: > > > > On Thu, Jan 4, 2024 at 11:59=E2=80=AFPM Thomas Monjalon > > 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 > > > > > > > > > > > > > > > > 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(). > > For consistency with rte_eth_rx_queue_count() regarding both naming and b= ehavior of the API, I would prefer: > > rte_eth_tx_queue_count(), returning the number of used descriptors. Ack. I will change to "used" version. > > > > > > > > > > > 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 =3D 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. > > Yes, rte_eth_rx/tx_queue_avail_count() could be added in the ethdev libra= ry, without driver callbacks, but simply getting data from configured descr= iptor ring sizes and rte_eth_rx/tx_queue_count(). > > PS: For naming conventions, I sought inspiration from the mempool library= . Also, I don't see any need to use "descs" as part of the names of the pro= posed functions. > > The driver callback can be either "free count" or "used count", whichever= is easier for the drivers to implement, or (preferably) whichever is likel= ier to be faster to execute in the most common case. I would assume that th= e TX descriptor "used count" is relatively low most of the time. I will change driver callback to "used count" to have better synergy with public ethdev API. >