From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id 1714FA04AE; Fri, 7 Aug 2020 09:41:31 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 63E522B87; Fri, 7 Aug 2020 09:41:30 +0200 (CEST) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) by dpdk.org (Postfix) with ESMTP id 3336C29D6 for ; Fri, 7 Aug 2020 09:41:28 +0200 (CEST) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 5F7B85C01DE; Fri, 7 Aug 2020 03:41:27 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute7.internal (MEProxy); Fri, 07 Aug 2020 03:41:27 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding:content-type; s=fm1; bh= 3vOrsBZ6w+3r4g5jeibEewZq0Xt5o7EEnpjpkliP8w8=; b=H6C5QEl/Yef2tGST PJLK7k3R+6ognQG9gXXcG8cLDbWk93wcqK7ln2XaXeRG4AxBK/K+5B1p55DMcd38 yMZtpP3Pi1F7ZHAIk8PGsCwb0WIqO/B2UWjjxhaGrQcJ0PPggccsNIIe8bcHFxUG mksIolyUL42TDzpFSnQP8yNmwaZlDhWfLWsyxyEkfFXfzMCD4gx2f2sU8rEaMMpZ ENEMFSGCBKvV8FBd7pibqr8DSFScdnigmsVMAFuIKkt3tNW3/D3tNStfFpXN1d0J AN04KhsmDLUSuFgF0cVeaydy+ow+PzZSe1VjuHfm+uqOkYfwnYPhaI9mF7vNLmTt IOHsHQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=3vOrsBZ6w+3r4g5jeibEewZq0Xt5o7EEnpjpkliP8 w8=; b=JWWuUoUVtRiKSHKHbhVAtuSH+pxc8o3cktWOVtMpsOG5z8e2EckNSDzNJ /hO866SHdqcWsHAReMDgZ+qm1PrJYpec7uMdny5vAmQS328hRdKcFJ5Wxw90j0Wd +BTRt/jVqWyXi+/5lM/2xDTWd144N1mGhXVbqjQ5GeQu/7FTHjArcL5qL8lfnTjW HtDswCWqEGwst4aXOkSmhbSUcJgUm474/95unl/mMzv1VWaat3LksVMRseCe4MHg wclm7RMPYDwcIFpt534X8jozI/nOinu20lCV8ThknjL7h9r67/IPXHocLsrBV8qn 8L7BrTzAHHsekBU28YJYVYJx2OhMQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduiedrkedugdduvdehucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhephffvufffkfgjfhgggfgtsehtufertddttddvnecuhfhrohhmpefvhhhomhgr shcuofhonhhjrghlohhnuceothhhohhmrghssehmohhnjhgrlhhonhdrnhgvtheqnecugg ftrfgrthhtvghrnhepffdvffejueetleefieeludduuefgteejleevfeekjeefieegheet ffdvkeefgedunecuffhomhgrihhnpeguphgukhdrohhrghenucfkphepjeejrddufeegrd dvtdefrddukeegnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhf rhhomhepthhhohhmrghssehmohhnjhgrlhhonhdrnhgvth X-ME-Proxy: Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184]) by mail.messagingengine.com (Postfix) with ESMTPA id EC06A30600A3; Fri, 7 Aug 2020 03:41:25 -0400 (EDT) From: Thomas Monjalon To: Ferruh Yigit , dev@dpdk.org, Chengchang Tang Cc: linuxarm@huawei.com, arybchenko@solarflare.com, stephen@networkplumber.org Date: Fri, 07 Aug 2020 09:41:24 +0200 Message-ID: <3745391.5RstSAbylj@thomas> In-Reply-To: <28901e93-639b-2e16-8a08-9cf939733262@huawei.com> References: <1596619484-19714-1-git-send-email-tangchengchang@huawei.com> <28901e93-639b-2e16-8a08-9cf939733262@huawei.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] [PATCH v2] doc: add new field to rxq info struct X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" For info, today is the last day to get trusted acks on deprecations. 07/08/2020 05:51, Chengchang Tang: > On 2020/8/6 23:25, Ferruh Yigit wrote: > > On 8/6/2020 5:00 AM, Chengchang Tang wrote: > >> Struct rte_eth_rxq_info will be modified to include a new field, indicating > >> the size of each buffer that could be used for hw to receive packets. Add > >> this field to rte_eth_rxq_info to expose relevant information to upper > >> layer users/application. > >> > >> For more details: > >> https://mails.dpdk.org/archives/dev/2020-July/176135.html > >> > >> Signed-off-by: Chengchang Tang > >> Acked-by: Andrew Rybchenko > >> --- > >> doc/guides/rel_notes/deprecation.rst | 9 +++++++++ > >> 1 file changed, 9 insertions(+) > >> > >> diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst > >> index ea4cfa7..f08b5f9 100644 > >> --- a/doc/guides/rel_notes/deprecation.rst > >> +++ b/doc/guides/rel_notes/deprecation.rst > >> @@ -110,6 +110,15 @@ Deprecation Notices > >> break the ABI checks, that is why change is planned for 20.11. > >> The list of internal APIs are mainly ones listed in ``rte_ethdev_driver.h``. > >> > >> +* ethdev: A new field will be added to the public data structure > >> + ``rte_eth_rxq_info`` to indicate the buffer size used in receiving packets > >> + for HW. When receive packets, HW DMA won't exceed this size. > > > > Overall +1 to provide this information. > > > > This field is only to report back the PMD configured Rx buffer size, it won't > > affect the configuration step, do you think should we highlight this? > I think it is not necessary because this structure is designed to report PMD > configuration. And it is only used in rte_eth_rx_queue_info_get. > > > > Also will this field be optional or mandatory, this matters for the scope of the > > work for 20.11. I think the intention is to provide an optional field, what do > > you think to documenting that it is optional? > Yes, it is optional. I will highlight this in v3. > > > >> And it will > >> + affect the number of fragments in receiving packets when scatter is enabled. > > > > Is this detail required in the deprecation notice? I see it is relevant but > > the configured Rx buffer size affects the number of the fragments, but reporting > > this value does not. > > Do you want to mention above as motivation to have the field? If so I don't > > expect application to calculate the number of the fragments using this value. > > I am for dropping above sentences if I am not missing anything. > Thank you for this advice. I am not sure what information should be reflected in > a deprecation notice. I seem to have added some redundant and inappropriate stuff. > I will drop these sentences in v3. > > > >> + So, add this field to ``rte_eth_rxq_info`` to expose relevant information to > >> + upper layer user/application. > > > > And not sure above sentences says anything new, looks like duplication to me. > > > >> + This change is planned for 20.11. For more details: > >> + https://mails.dpdk.org/archives/dev/2020-July/176135.html > >> + > >> * traffic manager: All traffic manager API's in ``rte_tm.h`` were mistakenly made > >> ABI stable in the v19.11 release. The TM maintainer and other contributors have > >> agreed to keep the TM APIs as experimental in expectation of additional spec > >> > > > > > > . > > > >