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 419FDA00C3; Tue, 13 Sep 2022 10:06:30 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id D0CFD40156; Tue, 13 Sep 2022 10:06:29 +0200 (CEST) Received: from shelob.oktetlabs.ru (shelob.oktetlabs.ru [91.220.146.113]) by mails.dpdk.org (Postfix) with ESMTP id 1210640151 for ; Tue, 13 Sep 2022 10:06:29 +0200 (CEST) Received: from [192.168.38.17] (aros.oktetlabs.ru [192.168.38.17]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by shelob.oktetlabs.ru (Postfix) with ESMTPSA id 64EE159; Tue, 13 Sep 2022 11:06:28 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 shelob.oktetlabs.ru 64EE159 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=oktetlabs.ru; s=default; t=1663056388; bh=XI3HP8JMC72JHPEB9jxm2GPrWoWFuZkDgpBOfmGRjTA=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=nTR14UCI2yxlQEfI4bS4lRWTixT4MF0TPhmWkHCbDl2iu016QxW3Va4ogluCHX4DP +j8VqNsIf4Ib9IaT4qWfKrMeBYP94rDhT7zB1uy156sV8a53zfAOr6G2YzW80YgKjU 1tT9gczqywqhYstkvuwMrkXT5JGgh/QLuRIIublU= Message-ID: Date: Tue, 13 Sep 2022 11:06:28 +0300 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.13.0 Subject: Re: [PATCH v3 1/3] ethdev: introduce pool sort capability Content-Language: en-US To: Hanumanth Pothula , Thomas Monjalon , Ferruh Yigit Cc: dev@dpdk.org, xuan.ding@intel.com, wenxuanx.wu@intel.com, xiaoyun.li@intel.com, stephen@networkplumber.org, yuanx.wang@intel.com, mdr@ashroe.eu, yuying.zhang@intel.com, qi.z.zhang@intel.com, viacheslavo@nvidia.com, jerinj@marvell.com, ndabilpuram@marvell.com References: <20220812172451.1208933-1-hpothula@marvell.com> <20220902070047.2812906-1-hpothula@marvell.com> From: Andrew Rybchenko Organization: OKTET Labs In-Reply-To: <20220902070047.2812906-1-hpothula@marvell.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit 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 On 9/2/22 10:00, Hanumanth Pothula wrote: > This patch adds support for the pool sort capability. "Add support for serveral (?) mbuf pools per Rx queue." I dislike the word "sort" in summary and the feature description. IMHO it is too restrictive for intended behaviour. The key feature here is just support for more than one mbuf pool per Rx queue. That's it. Everything else should be out of scope of the definiteion. If buffers from many pools are provided, the hardware may do whatever it wants with it. Use smaller buffers for small packets and bigger for big. Use bigger buffers for small packets if there is no small buffers available. Use big plus small buffer if Rx scatter is enabled and a packet fits in such combination. And so so on. I.e. the feature should be orthogoal to Rx scatter. Rx scatter just says if driver/application allows to chain mbufs to receive a packet. If Rx scatter is disabled, a packet must be delivered in a single mbuf (either big or small). If Rx scatter is enable, a packet may be delivered using a chain of mbufs obtained from provided pools (either just one or many if several pools are supported). Ideally the feature should be orthogonal to buffer split as well. I.e. provide many pools for different segments. May be it is an overkill to provide pools A and B for the first segment and C and D for the second. It could be limitted to the last segment only. If so, we need separate strcture (not rte_eth_rxseg) to pass many pools. IMHO, an array of mempools is sufficient - similar to Rx queue configuration. I.e. no extra length since data length may be derived from mempool element size. > Some of the HW has support for choosing memory pools based on the > packet's size. The pool sort capability allows PMD to choose a > memory pool based on the packet's length. > > This is often useful for saving the memory where the application > can create a different pool to steer the specific size of the > packet, thus enabling effective use of memory. > > For example, let's say HW has a capability of three pools, > - pool-1 size is 2K > - pool-2 size is > 2K and < 4K > - pool-3 size is > 4K > Here, > pool-1 can accommodate packets with sizes < 2K > pool-2 can accommodate packets with sizes > 2K and < 4K > pool-3 can accommodate packets with sizes > 4K > > With pool sort capability enabled in SW, an application may create > three pools of different sizes and send them to PMD. Allowing PMD > to program HW based on packet lengths. So that packets with less > than 2K are received on pool-1, packets with lengths between 2K > and 4K are received on pool-2 and finally packets greater than 4K > are received on pool-3. > > The following two capabilities are added to the rte_eth_rxseg_capa > structure, > 1. pool_sort --> tells pool sort capability is supported by HW. > 2. max_npool --> max number of pools supported by HW. > > Defined new structure rte_eth_rxseg_sort, to be used only when pool > sort capability is present. If required this may be extended further > to support more configurations. > > Signed-off-by: Hanumanth Pothula > > v3: > - Implemented Pool Sort capability as new Rx offload capability, > RTE_ETH_RX_OFFLOAD_BUFFER_SORT. > v2: > - Along with spec changes, uploading testpmd and driver changes. > --- [snip]