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 B3C3CA0548; Sun, 25 Apr 2021 18:42:59 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 32C604113E; Sun, 25 Apr 2021 18:42:59 +0200 (CEST) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) by mails.dpdk.org (Postfix) with ESMTP id 59FB14113C for ; Sun, 25 Apr 2021 18:42:58 +0200 (CEST) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id DE7B45C0049; Sun, 25 Apr 2021 12:42:57 -0400 (EDT) Received: from imap4 ([10.202.2.54]) by compute2.internal (MEProxy); Sun, 25 Apr 2021 12:42:57 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= mime-version:message-id:in-reply-to:references:date:from:to:cc :subject:content-type; s=fm1; bh=ecGlGzqVDKmfJCVHnB7Sa3nADZzQb4A GgAQy3QY6PvI=; b=OF2dKy1mRSyrz5LgqgteUXeseoEDNRHU/pbI/LWyZl3VOfp x9r7UpFwDqqjdLps/VJQZ/tcuuCA/cW7TEA1G95dRqwC73Pco7fVRK/bA1OFCCeQ R1dv/YfpAARgxbVfWJaCDNQVHvJgYo1Jb5Hf2iDpP/1hbpeTEC/T2A89uqpqTtHE R/5UkS+9wTj9sBBZN+NH7eNp1RW4l/3JDGoL/M+Mt8/oDaNKg3feu0ew7AW9CpIu TDt0ALRqTF0oudWyGGnPwdTQEcDYz+JlWHDObaH+e0a4eJaWYsjvbsBTyYku4sBZ MzjgrdD9PztF/9teDo1LWUHBYq/2BtL8WGNwN9w== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc: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=fm2; bh=ecGlGz qVDKmfJCVHnB7Sa3nADZzQb4AGgAQy3QY6PvI=; b=FBcr/lfSEAlZ7s1KnOszjL FytUvW3677M3xBFsvTcbEUri/BSp+DlkA6uuI6DYqSwUXFf6m1ak64ZJo7D3Fn/6 WkIvWj0B5DX8CzdiTVhn6OajJMxJLQxxrkSR3BztJVSsAD3ZDKUUmTnwlir9GpI1 I2wVFLJ4mkAFO5l28SQi5hoQuw+FletUZ/aKAzx2mjGuJ+iozSUgWZ4HIwLSn9i+ hZHTw9/u4Z4L7sWgrT/YFe4kAl90RAriBP0Al83vSd04W4oKPCOSpJWVW99vt1yI 6rc5C3x9bQrjhNknHYQJazXW61890vNY3eHljac7neVHm1IgAa8bMqdeNVAgB94A == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrvdduiedguddtiecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpefofgggkfgjfhffhffvufgtsehttdertderreejnecuhfhrohhmpedfvfhh ohhmrghsucfoohhnjhgrlhhonhdfuceothhhohhmrghssehmohhnjhgrlhhonhdrnhgvth eqnecuggftrfgrthhtvghrnhepgeevheetkeekgeevkedvfffgffeuffejheeggfduffdv veeiieefkeejkedvfeelnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrg hilhhfrhhomhepthhhohhmrghssehmohhnjhgrlhhonhdrnhgvth X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id E2A94160648; Sun, 25 Apr 2021 12:42:56 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.5.0-alpha0-403-gbc3c488b23-fm-20210419.005-gbc3c488b Mime-Version: 1.0 Message-Id: <6874f4c7-618a-4e58-96b8-f1cc7e7a310b@www.fastmail.com> In-Reply-To: References: <1618454426-21457-1-git-send-email-oulijun@huawei.com> <2292057.lhpI95xzKh@thomas> <04c856eb-7112-adf3-f072-ea1a5323c775@intel.com> <6803418.Bd1l75JkzX@thomas> Date: Sun, 25 Apr 2021 18:42:35 +0200 From: "Thomas Monjalon" To: "Ray Kinsella" , "Lijun Ou" , "Ferruh Yigit" Cc: dev@dpdk.org, linuxarm@openeuler.org Content-Type: text/plain Subject: Re: [dpdk-dev] =?utf-8?q?=5BPATCH_V4=5D_ethdev=3A_add_queue_state_wh?= =?utf-8?q?en_retrieve_queue_information?= 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 Sender: "dev" Kinsella, Ray: > On 16/04/2021 10:57, Thomas Monjalon wrote: > > 16/04/2021 11:41, Ferruh Yigit: > >> On 4/16/2021 9:58 AM, Thomas Monjalon wrote: > >>> 16/04/2021 10:46, Lijun Ou: > >>>> Currently, upper-layer application could get queue state only > >>>> through pointers such as dev->data->tx_queue_state[queue_id], > >>>> this is not the recommended way to access it. So this patch > >>>> add get queue state when call rte_eth_rx_queue_info_get and > >>>> rte_eth_tx_queue_info_get API. > >>>> > >>>> Note: After add queue_state field, the 'struct rte_eth_rxq_info' size > >>>> remains 128B, and the 'struct rte_eth_txq_info' size remains 64B, so > >>>> it could be ABI compatible. > >>> [...] > >>>> --- a/doc/guides/rel_notes/release_21_05.rst > >>>> +++ b/doc/guides/rel_notes/release_21_05.rst > >>>> @@ -251,6 +251,12 @@ ABI Changes > >>>> function was already marked as internal in the API documentation for it, > >>>> and was not for use by external applications. > >>>> > >>>> +* Added new field ``queue_state`` to ``rte_eth_rxq_info`` structure > >>>> + to provide indicated rxq queue state. > >>>> + > >>>> +* Added new field ``queue_state`` to ``rte_eth_txq_info`` structure > >>>> + to provide indicated txq queue state. > >>> > >>> Not sure we should add a note here for additions which > >>> do not break ABI compatibility. > >>> It may be confusing. > >>> > >> > >> Hi Thomas, > >> > >> What do about adding the documentation to "API Changes" section? > >> Since 'rte_eth_rx_queue_info_get()'/'rte_eth_tx_queue_info_get()' can get > >> 'queue_state' now, which may taken as API change. > > > > That's an addition. > > The users have nothing to change in their existing code, > > so I think we don't need a note in API or ABI change. > > The only required note would be in the "New Features". > > Well it definitely isn't an ABI change, however it still is an API addition. > I don't know, if additions qualify as changes. Additions are already notified in the section "New Features" in general. The purpose of the API section in the release notes is for app developers to be warned of changes requiring attention in their maintenance.