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 DABDFA04B1 for ; Wed, 4 Nov 2020 11:35:17 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 96CAFC8C4; Wed, 4 Nov 2020 11:35:16 +0100 (CET) Received: from szxga05-in.huawei.com (szxga05-in.huawei.com [45.249.212.191]) by dpdk.org (Postfix) with ESMTP id 61296C8C4 for ; Wed, 4 Nov 2020 11:35:15 +0100 (CET) Received: from DGGEMS405-HUB.china.huawei.com (unknown [172.30.72.59]) by szxga05-in.huawei.com (SkyGuard) with ESMTP id 4CR3216hmwzhfjV; Wed, 4 Nov 2020 18:35:05 +0800 (CST) Received: from [10.67.103.119] (10.67.103.119) by DGGEMS405-HUB.china.huawei.com (10.3.19.205) with Microsoft SMTP Server id 14.3.487.0; Wed, 4 Nov 2020 18:35:02 +0800 To: Luca Boccassi , CC: References: <1604394260-9644-1-git-send-email-oulijun@huawei.com> From: oulijun Message-ID: Date: Wed, 4 Nov 2020 18:35:03 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [10.67.103.119] X-CFilter-Loop: Reflected Subject: Re: [dpdk-stable] [PATCH 19.11.6] ethdev: fix data type in TC queues X-BeenThere: stable@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches for DPDK stable branches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: stable-bounces@dpdk.org Sender: "stable" 在 2020/11/3 17:21, Luca Boccassi 写道: > On Tue, 2020-11-03 at 17:04 +0800, Lijun Ou wrote: >> From: Huisong Li >> >> [ upstream commit 9f6dc8592d54aa2ec1800c53977a31bd7922147b ] >> >> Currently, base and nb_queue in the tc_rxq and tc_txq information >> of queue and TC mapping on both TX and RX paths are uint8_t. >> However, these data will be truncated when queue number under a TC >> is greater than 256. So it is necessary for base and nb_queue to >> change from uint8_t to uint16_t. >> >> Fixes: 89d6728c7837 ("ethdev: get DCB information") >> Cc: stable@dpdk.org >> >> Signed-off-by: Huisong Li >> Signed-off-by: Min Hu (Connor) >> Reviewed-by: Wei Hu (Xavier) >> Reviewed-by: Dongdong Liu >> Acked-by: Thomas Monjalon >> Reviewed-by: Ferruh Yigit >> --- >> doc/guides/rel_notes/release_19_11.rst | 5 +++++ >> lib/librte_ethdev/rte_ethdev.h | 8 ++++---- >> 2 files changed, 9 insertions(+), 4 deletions(-) >> >> diff --git a/doc/guides/rel_notes/release_19_11.rst b/doc/guides/rel_notes/release_19_11.rst >> index acd18a3..cba8ebd 100644 >> --- a/doc/guides/rel_notes/release_19_11.rst >> +++ b/doc/guides/rel_notes/release_19_11.rst >> @@ -457,6 +457,11 @@ API Changes >> * ethdev: changed ``rte_eth_dev_owner_delete`` return value from ``void`` to >> ``int`` to provide a way to report various error conditions. >> >> +* ethdev: Modified field type of ``base`` and ``nb_queue`` in struct >> + ``rte_eth_dcb_tc_queue_mapping`` from ``uint8_t`` to ``uint16_t``. >> + As the data of ``uint8_t`` will be truncated when queue number under >> + a TC is greater than 256. >> + >> * ethdev: The deprecated function ``rte_eth_dev_count`` was removed. >> The function ``rte_eth_dev_count_avail`` is a drop-in replacement. >> If the intent is to iterate over ports, ``RTE_ETH_FOREACH_*`` macros >> diff --git a/lib/librte_ethdev/rte_ethdev.h b/lib/librte_ethdev/rte_ethdev.h >> index 51f9f25..5fedff0 100644 >> --- a/lib/librte_ethdev/rte_ethdev.h >> +++ b/lib/librte_ethdev/rte_ethdev.h >> @@ -1360,13 +1360,13 @@ struct rte_eth_xstat_name { >> struct rte_eth_dcb_tc_queue_mapping { >> /** rx queues assigned to tc per Pool */ >> struct { >> - uint8_t base; >> - uint8_t nb_queue; >> + uint16_t base; >> + uint16_t nb_queue; >> } tc_rxq[ETH_MAX_VMDQ_POOL][ETH_DCB_NUM_TCS]; >> /** rx queues assigned to tc per Pool */ >> struct { >> - uint8_t base; >> - uint8_t nb_queue; >> + uint16_t base; >> + uint16_t nb_queue; >> } tc_txq[ETH_MAX_VMDQ_POOL][ETH_DCB_NUM_TCS]; >> }; > > Hi, > > Thanks for the patch, but isn't this an ABI breakage? This is a public > header right? > I understand that an ABI breakage has been announced.