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 EBE41A04FD;
	Mon, 23 May 2022 12:59:03 +0200 (CEST)
Received: from [217.70.189.124] (localhost [127.0.0.1])
	by mails.dpdk.org (Postfix) with ESMTP id A360440141;
	Mon, 23 May 2022 12:59:03 +0200 (CEST)
Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com
 [66.111.4.28]) by mails.dpdk.org (Postfix) with ESMTP id 95D3640041
 for <dev@dpdk.org>; Mon, 23 May 2022 12:59:01 +0200 (CEST)
Received: from compute4.internal (compute4.nyi.internal [10.202.2.44])
 by mailout.nyi.internal (Postfix) with ESMTP id DEFE25C00C6;
 Mon, 23 May 2022 06:59:00 -0400 (EDT)
Received: from mailfrontend1 ([10.202.2.162])
 by compute4.internal (MEProxy); Mon, 23 May 2022 06:59:00 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h=
 cc:cc:content-transfer-encoding:content-type:date:date:from:from
 :in-reply-to:in-reply-to:message-id:mime-version:references
 :reply-to:sender:subject:subject:to:to; s=fm1; t=1653303540; x=
 1653389940; bh=BifSGu/ljj7qngxKIonq6BUuz9MWq1rzOVgGzgHcqMM=; b=c
 yeuk815CQFFVGC5cO6uxon9ukRYnt1bIighR9zbyrbcIMSr3llWZs7Tq9j9ifUNo
 EjaIXgbbx6s4ClxWq2l2ihOLNGHaDnVLO1tTqSASq5GWLOBhOmrdOu59hgEsVgzf
 gcYnYV8r7mll9fVLaDQLXr9FeHyndb7kNijOMM4umxlyxWoSy7xWh1oCUUyhMSp5
 9nDtZYq4ZhujHZ0rizdgF4I/JozLMpeThc0G+4LRyVTlENPG7aJfLEmN9lCcTmmk
 OsvVJC73rGoI6eJZXUM/2/597t2j8rJ9/smGoRoJ19vMQQ+YwHjMEGnk1HDGvnmY
 QPxpGHuuQidT82i7F7Vzg==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
 messagingengine.com; h=cc:cc:content-transfer-encoding
 :content-type:date:date:feedback-id:feedback-id:from:from
 :in-reply-to:in-reply-to:message-id:mime-version:references
 :reply-to:sender:subject:subject:to:to:x-me-proxy:x-me-proxy
 :x-me-sender:x-me-sender:x-sasl-enc; s=fm1; t=1653303540; x=
 1653389940; bh=BifSGu/ljj7qngxKIonq6BUuz9MWq1rzOVgGzgHcqMM=; b=T
 x96MAM4MNz+LXrPz+ODlguytzQL5iLesj3mhql+QWiIlYx7ZKKip2qWpTGd8YYDg
 3yChAjyj5Ci0sNAJePXMQvFcvlZiWVVQacqC7wMhg/8lGsPAAwt+PBVbv4aeFt6v
 rcRaoPK4vwfSy95GsbzrfPPc5T1m/6/MZmG83Le9Y8zwZMx3MNf6ccjDSoqeQopy
 fmlrj+ChDT4dMeWN/sdc6hJG8+okbmtimCq7kvrlSocG2KIUJbcioDq3ex3rO2Ax
 w90DYXEI4iduFzPvTheyw1kicxOwj5+90CrDxZ0iFVocFZXIMUrPv/oFGuaKCbaf
 TCmgoZNI4JKcbc0cpd8CA==
X-ME-Sender: <xms:9GiLYsZxzlD5py8jBNTJzQ1uSYCeS5GMf5eoLe_YXj2z0hlsiOxCVg>
 <xme:9GiLYnZxnMDWesC3ujhGRC3e2xCxUBhMuf6le6kfmPwFIlm-h-f4-LaSxRSAuHXtw
 AE-71WWC-tsSQ4Gqg>
X-ME-Received: <xmr:9GiLYm-rtHQUeTJ2hZxW8UOHhpuRYsCqMcySt63uwRIuK0KAGgqlyJo8s_3Q-Rtb2-cIltegVq0_76Og9lJjiJ63fQSz631evC_MRklXBJE>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvfedrjedugddthecutefuodetggdotefrodftvf
 curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu
 uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc
 fjughrpefhvfevufffkfgjfhgggfgtsehtqhertddttddunecuhfhrohhmpefvhhhomhgr
 shcuofhonhhjrghlohhnuceothhhohhmrghssehmohhnjhgrlhhonhdrnhgvtheqnecugg
 ftrfgrthhtvghrnhepfefhjeeluedvvedtuddtuedtvefhieejtefhffeujefhteduudev
 tdektdeikeffnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrh
 homhepthhhohhmrghssehmohhnjhgrlhhonhdrnhgvth
X-ME-Proxy: <xmx:9GiLYmokKpQUDdH__FTl5A2H0XPj0beQW4YAy8vtDrvVOqrEe0NtCg>
 <xmx:9GiLYnqBpKwiSywWOnXYjPvuEoiug0jvdNFbFLrTiInIfy9Mrz504Q>
 <xmx:9GiLYkRZvffI3g4wuQ6yzxIWc6tx3OKBySgeKY7IfYn9VlGXwZ6iYA>
 <xmx:9GiLYoCJbrpyoAIIt5FQCIQFEOzM94FTD_vIK4xtdadJdaZQiI8qJA>
Feedback-ID: i47234305:Fastmail
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Mon,
 23 May 2022 06:58:58 -0400 (EDT)
From: Thomas Monjalon <thomas@monjalon.net>
To: Spike Du <spiked@nvidia.com>,
 Morten =?ISO-8859-1?Q?Br=F8rup?= <mb@smartsharesystems.com>
Cc: matan@nvidia.com, viacheslavo@nvidia.com, orika@nvidia.com, dev@dpdk.org,
 rasland@nvidia.com
Subject: Re: [RFC v2 3/7] ethdev: introduce Rx queue based limit watermark
Date: Mon, 23 May 2022 12:58:50 +0200
Message-ID: <3249537.9LS3J3VOpE@thomas>
In-Reply-To: <98CBD80474FA8B44BF855DF32C47DC35D87097@smartserver.smartshare.dk>
References: <20220506035645.4101714-1-spiked@nvidia.com>
 <20220522055900.417282-4-spiked@nvidia.com>
 <98CBD80474FA8B44BF855DF32C47DC35D87097@smartserver.smartshare.dk>
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="iso-8859-1"
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

23/05/2022 08:07, Morten Br=F8rup:
> > +	uint8_t lwm;
>=20
> Why percentage, why not 1/128th, or 1/16th? 2^N seems more logical, and I=
 wonder if such high granularity is really necessary. Just a thought, it's =
not important.

I think percentage is the easiest to understand
and to share with other teams in design documents.

> If you stick with percentage, it only needs 7 bits, and you can make the =
remaining one bit reserved.
>=20
> Also, please add here that 0 means disable.

Good idea.