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 AE771A04B5; Mon, 7 Sep 2020 14:06:48 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id A8A911C0D5; Mon, 7 Sep 2020 14:06:47 +0200 (CEST) Received: from huawei.com (szxga05-in.huawei.com [45.249.212.191]) by dpdk.org (Postfix) with ESMTP id 9A84C1C0D1 for ; Mon, 7 Sep 2020 14:06:45 +0200 (CEST) Received: from DGGEMS401-HUB.china.huawei.com (unknown [172.30.72.60]) by Forcepoint Email with ESMTP id B3D44FFBD3FA473A7ECC; Mon, 7 Sep 2020 20:06:42 +0800 (CST) Received: from [127.0.0.1] (10.65.81.238) by DGGEMS401-HUB.china.huawei.com (10.3.19.201) with Microsoft SMTP Server id 14.3.487.0; Mon, 7 Sep 2020 20:06:33 +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> <1a4dc7d6-5596-34cb-9eb1-adcd2adef2fb@huawei.com> <66ecf741-ac5b-cf61-66f3-c5df59c1bd49@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: <5defff09-c8f8-a8f4-b137-0c62ebff2710@huawei.com> Date: Mon, 7 Sep 2020 20:06:32 +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/7 16:28, Matan Azrad wrote: > > Hi Chengchang > > From: Chengchang Tang: >> Hi Matan >> >> On 2020/9/6 21:45, Matan Azrad wrote: >>> >>> Hi Chengchang >>> >>> From: Chengchang Tang: >>>> Hi, Matan >>>> >>>> On 2020/9/2 18:30, Matan Azrad wrote: >>>>> Hi Chengchang >>>>> >>>>> From: Chengchang Tang >>>>>> Hi, Matan >>>>>> >>>>>> On 2020/9/2 15:19, Matan Azrad wrote: >>>>>>> >>>>>>> Hi Chengchang >>>>>>> >>>>>>> From: Chengchang Tang >>>>>>>> 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(+) >>>>>>>>>> > >>>>> So the user can configure X and the driver will use Y!=X? >>>> >>>> Yes, it depends on the HW. In the queue setup API, it just checks >>>> whether the input is greater than the required minimum value. But HW >>>> usually has requirements for alignment and so on. >>>> So when X does not meet these requirements, PMDs will calculate a new >>>> value Y that meets these requirements to configure the hardware (Y <= >>>> X, to ensure no memory overflow occurs). >>>>> Should the application validate its own configurations after setting >>>>> them >>>> successfully? >>>> >>>> It depends on their own needs. The application should not be forced >>>> to verify it to avoid affecting the ease of use of PMDs. For some >>>> applications, they don't care about this value. >>> >>> I understand, >>> It looks me like a bad ping-pong between app and PMD (for all the >>> fields in the struct), And we should avoid adding fields to this structure if >> we can. >>> >>> What's about adding field in rte_eth_dev_info to expose the rx buffer >> alignment supported by the PMD? >>> Then, application has all the knowledge you want to expose before the >> configuration. >> >> This may not work because there may be other restrictions besides >> alignment, which are related to the hardware design. Therefore, it is difficult >> to describe all constraints in a single field. >> Moreover, this approach seems to >> constrain the PMDs and HW to some extent. > > Ok, so maybe other ethdev capability API to get the Rx buffer size adjustment by the PMD? > Don't you think it is important information to the application in order to decide the mempool buffer size \ enabling scatter? I guess what you mean is that it's more like a capability, so the application should query it through a capability API. If i understand correctly, I agree with that. But I think it's okay to use this structure to export queue related information at runtime. It focuses on querying the current queue configuration. And there seems to be no suitable API for querying this capability. Maybe we need to introduce a new API to do this. But I'm not sure if it's really necessary. > > In any case, I think you should add documentation in the RX setup API that the HW buf size may be changed by the PMD. There is not a defined rule of how to configure Rx buffer size. That is, there is no specific method to configure the Rx buffer size for applications. However, most PMDs configure the Rx buffer size base on the data size of the mempool. So, if the description is added to the setup API, the method for configuring the Rx buffer size is determined. I think this issue should involve more people in the discussion, maybe we should send a separate patch. > > > > . >