From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <dev-bounces@dpdk.org>
Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124])
	by inbox.dpdk.org (Postfix) with ESMTP id E37E743869;
	Mon,  8 Jan 2024 22:15:45 +0100 (CET)
Received: from mails.dpdk.org (localhost [127.0.0.1])
	by mails.dpdk.org (Postfix) with ESMTP id 78FB640272;
	Mon,  8 Jan 2024 22:15:45 +0100 (CET)
Received: from dkmailrelay1.smartsharesystems.com
 (smartserver.smartsharesystems.com [77.243.40.215])
 by mails.dpdk.org (Postfix) with ESMTP id DA9A840263
 for <dev@dpdk.org>; Mon,  8 Jan 2024 22:15:43 +0100 (CET)
Received: from smartserver.smartsharesystems.com
 (smartserver.smartsharesys.local [192.168.4.10])
 by dkmailrelay1.smartsharesystems.com (Postfix) with ESMTP id 82AE320E80;
 Mon,  8 Jan 2024 22:15:43 +0100 (CET)
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [dpdk-dev] [RFC] ethdev: support Tx queue free descriptor query
X-MimeOLE: Produced By Microsoft Exchange V6.5
Date: Mon, 8 Jan 2024 22:15:40 +0100
Message-ID: <98CBD80474FA8B44BF855DF32C47DC35E9F11E@smartserver.smartshare.dk>
In-Reply-To: <ZZvUXA3Jh0DqemLB@bricha3-MOBL.ger.corp.intel.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [dpdk-dev] [RFC] ethdev: support Tx queue free descriptor query
Thread-Index: AdpCIR1fxk0kjQeDQaGNJxLtThZ+vgAVOI7A
References: <20231219172948.3909749-1-jerinj@marvell.com>
 <ZZvUXA3Jh0DqemLB@bricha3-MOBL.ger.corp.intel.com>
From: =?iso-8859-1?Q?Morten_Br=F8rup?= <mb@smartsharesystems.com>
To: "Bruce Richardson" <bruce.richardson@intel.com>,
	<jerinj@marvell.com>
Cc: <dev@dpdk.org>, "Thomas Monjalon" <thomas@monjalon.net>,
 "Ferruh Yigit" <ferruh.yigit@amd.com>,
 "Andrew Rybchenko" <andrew.rybchenko@oktetlabs.ru>,
 <ferruh.yigit@xilinx.com>, <ajit.khaparde@broadcom.com>,
 <aboyer@pensando.io>, <beilei.xing@intel.com>, <chas3@att.com>,
 <chenbo.xia@intel.com>, <ciara.loftus@intel.com>,
 <dsinghrawat@marvell.com>, <ed.czeck@atomicrules.com>,
 <evgenys@amazon.com>, <grive@u256.net>, <g.singh@nxp.com>,
 <zhouguoyang@huawei.com>, <haiyue.wang@intel.com>, <hkalra@marvell.com>,
 <heinrich.kuhn@corigine.com>, <hemant.agrawal@nxp.com>,
 <hyonkim@cisco.com>, <igorch@amazon.com>, <irusskikh@marvell.com>,
 <jgrajcia@cisco.com>, <jasvinder.singh@intel.com>,
 <jianwang@trustnetic.com>, <jiawenwu@trustnetic.com>,
 <jingjing.wu@intel.com>, <johndale@cisco.com>,
 <john.miller@atomicrules.com>, <linville@tuxdriver.com>,
 <keith.wiles@intel.com>, <kirankumark@marvell.com>, <oulijun@huawei.com>,
 <lironh@marvell.com>, <longli@microsoft.com>, <mw@semihalf.com>,
 <spinler@cesnet.cz>, <matan@nvidia.com>, <matt.peters@windriver.com>,
 <maxime.coquelin@redhat.com>, <mk@semihalf.com>, <humin29@huawei.com>,
 <pnalla@marvell.com>, <ndabilpuram@marvell.com>, <qiming.yang@intel.com>,
 <qi.z.zhang@intel.com>, <radhac@marvell.com>,
 <rahul.lakkireddy@chelsio.com>, <rmody@marvell.com>, <rosen.xu@intel.com>,
 <sachin.saxena@oss.nxp.com>, <skoteshwar@marvell.com>,
 <shshaikh@marvell.com>, <shaibran@amazon.com>,
 <shepard.siegel@atomicrules.com>, <asomalap@amd.com>,
 <somnath.kotur@broadcom.com>, <sthemmin@microsoft.com>,
 <steven.webster@windriver.com>, <skori@marvell.com>, <mtetsuyah@gmail.com>,
 <vburru@marvell.com>, <viacheslavo@nvidia.com>, <xiao.w.wang@intel.com>,
 <cloud.wangxiaoyun@huawei.com>, <yisen.zhuang@huawei.com>,
 <yongwang@vmware.com>, <xuanziyang2@huawei.com>,
 <cristian.dumitrescu@intel.com>
X-BeenThere: dev@dpdk.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: DPDK patches and discussions <dev.dpdk.org>
List-Unsubscribe: <https://mails.dpdk.org/options/dev>,
 <mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://mails.dpdk.org/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <https://mails.dpdk.org/listinfo/dev>,
 <mailto:dev-request@dpdk.org?subject=subscribe>
Errors-To: dev-bounces@dpdk.org

> From: Bruce Richardson [mailto:bruce.richardson@intel.com]
> Sent: Monday, 8 January 2024 11.54
>=20
> On Tue, Dec 19, 2023 at 10:59:48PM +0530, jerinj@marvell.com wrote:
> > From: Jerin Jacob <jerinj@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 <jerinj@marvell.com>
> > ---
>=20
> Hi Jerin,
>=20
> while I don't strongly object to this patch, I wonder if it encourages
> sub-optimal code implementations. To determine the number of free
> descriptors in a ring, the driver in many cases will need to do a scan
> of
> the descriptor ring to see how many are free/used. However, I suspect
> that
> in most cases we will see something like the following being done:
>=20
>     count =3D rte_eth_rx_free_count();

Typo: rte_eth_rx_free_count() -> rte_eth_tx_free_count()

>     if (count > X) {
>         /* Do something */
>     }
>=20
> For instances like this, scanning the entire ring is wasteful of
> resources.
> Instead it would be better to just check the descriptor at position X
> explicitly. Going to the trouble of checking the exact descriptor =
count
> is
> unnecessary in this case.

Yes, it introduces such a risk.
All DPDK examples simply call tx_burst() without checking free space =
first, so I think the probability (of the simple case) is low.
And the probability for the case comparing to X could be mitigated by =
referring to rte_eth_tx_descriptor_status() in the function description.

>=20
> Out of interest, are you aware of a case where an app would need to
> know
> exactly the number of free descriptors, and where the result would not
> be
> just compared to one or more threshold values? Do we see cases where =
it
> would be used in a computation, perhaps?

Yes: RED. When exceeding the minimum threshold, the probability of =
marking/dropping a packet increases linearly with the queue's fill =
level.
E.g.:
0-900 packets in queue: don't drop,
901-1000 packets in queue: probability of dropping the packet is 1-100 % =
(e.g. 980 packets in queue =3D 80 % drop probability).