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 3CC80A0548; Mon, 26 Apr 2021 11:48:36 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 1231241110; Mon, 26 Apr 2021 11:48:36 +0200 (CEST) Received: from mail-108-mta131.mxroute.com (mail-108-mta131.mxroute.com [136.175.108.131]) by mails.dpdk.org (Postfix) with ESMTP id B904940140 for ; Mon, 26 Apr 2021 11:48:33 +0200 (CEST) Received: from filter004.mxroute.com ([149.28.56.236] filter004.mxroute.com) (Authenticated sender: mN4UYu2MZsgR) by mail-108-mta131.mxroute.com (ZoneMTA) with ESMTPSA id 1790d948d0c0004964.001 for (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES128-GCM-SHA256); Mon, 26 Apr 2021 09:48:29 +0000 X-Zone-Loop: fe40efb90b23f11ad3aeabfa13586c1249576333952c X-Originating-IP: [149.28.56.236] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=ashroe.eu; s=x; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version:Date: Message-ID:From:References:Cc:To:Subject:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=ydFxbNGU8CTmihbaM7I2lXNiX7roD4HIicww+UixbxE=; b=hW57CPOeyEG4e+qMWRsNmbqOWu MH41r3+PLW3S26V4gIQhB/NWPnpGjXRfvUGMAVW6bEe7mwU89j4x9ICa78Vju38eNVukOGz1bCN1J HcjxtzbqU79PLa7gI4R8k3S7+XxMdHq7466h+R35vStDlFrvXBnwGw68UpYUCJ/aix4P9CAShrHDc eksJLXEwqIFiaXJqEmqc1p86oMSyaeuTnH4Xh4/Wd7JlCUV4zh2mTEPIy+hdnUX5GskPfkq4KjGGG eYN8i2nLAo58cSYQKYyB+ZDHmybLpv7RnJucQokALIrF0StGZ7AAkIIkCTXcqRdzfHJynXoFMVvyU 8qcEce7A==; To: Thomas Monjalon , Lijun Ou , Ferruh Yigit Cc: dev@dpdk.org, linuxarm@openeuler.org References: <1618454426-21457-1-git-send-email-oulijun@huawei.com> <2292057.lhpI95xzKh@thomas> <04c856eb-7112-adf3-f072-ea1a5323c775@intel.com> <6803418.Bd1l75JkzX@thomas> <6874f4c7-618a-4e58-96b8-f1cc7e7a310b@www.fastmail.com> From: "Kinsella, Ray" Message-ID: Date: Mon, 26 Apr 2021 10:48:26 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.0 MIME-Version: 1.0 In-Reply-To: <6874f4c7-618a-4e58-96b8-f1cc7e7a310b@www.fastmail.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-AuthUser: mdr@ashroe.eu Subject: Re: [dpdk-dev] [PATCH V4] ethdev: add queue state when 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" On 25/04/2021 17:42, Thomas Monjalon wrote: > 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. > Understood - thanks. Ray K