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 D7623A04B5; Wed, 2 Sep 2020 05:52:15 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 262D4137D; Wed, 2 Sep 2020 05:52:15 +0200 (CEST) Received: from huawei.com (szxga05-in.huawei.com [45.249.212.191]) by dpdk.org (Postfix) with ESMTP id A0473255 for ; Wed, 2 Sep 2020 05:52:13 +0200 (CEST) Received: from DGGEMS409-HUB.china.huawei.com (unknown [172.30.72.58]) by Forcepoint Email with ESMTP id 0E594F8305DEDA09D116; Wed, 2 Sep 2020 11:52:11 +0800 (CST) Received: from [127.0.0.1] (10.65.81.238) by DGGEMS409-HUB.china.huawei.com (10.3.19.209) with Microsoft SMTP Server id 14.3.487.0; Wed, 2 Sep 2020 11:52:05 +0800 To: Matan Azrad , "dev@dpdk.org" References: <1592483709-7076-1-git-send-email-tangchengchang@huawei.com> <1598685199-1630-1-git-send-email-tangchengchang@huawei.com> <1598685199-1630-2-git-send-email-tangchengchang@huawei.com> CC: "maryam.tahhan@intel.com" , "linuxarm@huawei.com" , "ferruh.yigit@intel.com" , "wenzhuo.lu@intel.com" , NBU-Contact-Thomas Monjalon , "arybchenko@solarflare.com" From: Chengchang Tang Message-ID: Date: Wed, 2 Sep 2020 11:52:03 +0800 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 7bit X-Originating-IP: [10.65.81.238] X-CFilter-Loop: Reflected Subject: Re: [dpdk-dev] [PATCH v3 1/4] ethdev: add a field for rxq info structure 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" Hi, Matan On 2020/9/1 23:33, Matan Azrad wrote: > > Hi Chengchang > > Please see some question below. > > From: Chengchang Tang >> Add a field named rx_buf_size in rte_eth_rxq_info to indicate the buffer size >> used in receiving packets for HW. >> >> In this way, upper-layer users can get this information by calling >> rte_eth_rx_queue_info_get. >> >> Signed-off-by: Chengchang Tang >> Reviewed-by: Wei Hu (Xavier) >> Acked-by: Andrew Rybchenko >> --- >> lib/librte_ethdev/rte_ethdev.h | 2 ++ >> 1 file changed, 2 insertions(+) >> >> diff --git a/lib/librte_ethdev/rte_ethdev.h b/lib/librte_ethdev/rte_ethdev.h >> index 70295d7..9fed5cb 100644 >> --- a/lib/librte_ethdev/rte_ethdev.h >> +++ b/lib/librte_ethdev/rte_ethdev.h >> @@ -1420,6 +1420,8 @@ struct rte_eth_rxq_info { >> struct rte_eth_rxconf conf; /**< queue config parameters. */ >> uint8_t scattered_rx; /**< scattered packets RX supported. */ >> uint16_t nb_desc; /**< configured number of RXDs. */ >> + /**< buffer size used for hardware when receive packets. */ >> + uint16_t rx_buf_size; > > Is it the maximum supported Rx buffer by the HW? > If yes, maybe max_rx_buf_size is better name? No, it is the Rx buffer size currently used by HW. IMHO, the structure rte_eth_rxq_info and associated query API are mainly used to query HW configurations at runtime or after queue is configured/setup. Therefore, the content of this structure should be the current HW configuration. > Maybe document that 0 means - no limitation by HW? Yes, there is no need to fill this filed for HW that has no restrictions on it. I'll add it in v4. > Must application read it in order to know if its datapath should handle multi-segment buffers? I think it's more appropriate to use scattered_rx to determine if multi-segment buffers should be handled. > > Maybe it will be good to force application to configure scatter when this field is valid and smaller than max_rx_pkt_len\max_lro.. (<= room size)... > > >> } __rte_cache_min_aligned; >> >> /**