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 418E3A0543; Fri, 12 Aug 2022 15:27:42 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id E2D7C40A7F; Fri, 12 Aug 2022 15:27:41 +0200 (CEST) Received: from smartserver.smartsharesystems.com (smartserver.smartsharesystems.com [77.243.40.215]) by mails.dpdk.org (Postfix) with ESMTP id 708F4406A2 for ; Fri, 12 Aug 2022 15:27:41 +0200 (CEST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [PATCH v1 1/1] ethdev: introduce pool sort capability Date: Fri, 12 Aug 2022 15:27:38 +0200 Message-ID: <98CBD80474FA8B44BF855DF32C47DC35D8725F@smartserver.smartshare.dk> In-Reply-To: <20220812104648.1019978-1-hpothula@marvell.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PATCH v1 1/1] ethdev: introduce pool sort capability Thread-Index: AdiuOThLC69IZpEfTYmQzKywLV/DmQAESZ0Q References: <20220812104648.1019978-1-hpothula@marvell.com> From: =?iso-8859-1?Q?Morten_Br=F8rup?= To: "Hanumanth Pothula" , "Thomas Monjalon" , "Ferruh Yigit" , "Andrew Rybchenko" Cc: , , , , , , , , , , , 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 > From: Hanumanth Pothula [mailto:hpothula@marvell.com] > Sent: Friday, 12 August 2022 12.47 >=20 > Presently, the 'Buffer Split' feature supports sending multiple > segments of the received packet to PMD, which programs the HW > to receive the packet in segments from different pools. >=20 > This patch extends the feature to support the pool sort capability. > 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. >=20 > 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. >=20 > 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 >=20 > 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. >=20 > 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. >=20 > 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. >=20 > Signed-off-by: Hanumanth Pothula > Change-Id: I5a2485a7919616902c468c767b5c01834d4a2c27 > --- I like the concept of a PMD being able to use different mbuf pools = depending on packet size. However, the "pool sort" feature is not an extension of the "buffer = split" feature, but a separate feature. The API and documentation must = reflect this. Please also consider this, when you implement it in the drivers: If no = buffers are available in one of the pools, the next (larger) pool should = be used instead of dropping the packet. Here's another example use case: Assuming that 25 % of internet traffic = is tiny packets (e.g. empty TCP ACK packets), a separate pool for those = could be used.