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 672F7A00C3; Tue, 13 Sep 2022 11:31:26 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 091B340156; Tue, 13 Sep 2022 11:31:26 +0200 (CEST) Received: from NAM12-DM6-obe.outbound.protection.outlook.com (mail-dm6nam12on2047.outbound.protection.outlook.com [40.107.243.47]) by mails.dpdk.org (Postfix) with ESMTP id 0559240151 for ; Tue, 13 Sep 2022 11:31:24 +0200 (CEST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=WXPsa1A9WGl6y/oi6AHHOFrWSKmzRknvqYvUjOWsb3wTLdmDh1OZxKf5GXRIzvHzKTxluMXTimkAM8Mq7tyOXY0/vIbQ6px0hDRBt9Hg8lzniQ6KwtROYCIB0uRyA2VXs06OmbvT/2naBzCBIUWl/uVmgjR/aTb87zyo417vvW+C/ZBWLYQQaE3lqRfw2s314PZi454fww1Xgab/d0E1K2E60uy/vrqOCsmrHmSQY/+hMIyXHTmq88N5Ot01x1kUaLaWxIsbmMqZhO5XrsPoD05hmsoYdO6qttvfb6MKfXcaZ7iNIJJRX5gd/JhbQIcTTvNv9OhHNk3j5x5LhjZV5w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=h5SKb2AZaGsOGz58T6btpIY0YFRUA87FKgRPh8gdotQ=; b=KkMK+3dBoz/fGEFTuGRGvWhMsY5ebd6EguwOhjRfSUMzO6GhhsOvgV9Us0HCx+NjkI79KYpwro3lXN44iiY9F70Ks8Ul+LTjiJQYOIIAXg87fyTB9dt3Qke+vzgQL1Eknn4wpmaWk3lOmpCdPwan6IQtqzxsh77cDVlJBE++EoMuBIYMx+e7icyR9vj8h+xpnhaDCeZIu9xHqIineCzKPcm91319u2pxInSqqd0CFGnWAwA0BV91SCQaApZj3fYlw+t8RIfZsHbNczKTtmfCj/tMqGJKErX/krIbYPBhR4eq6OPOw9giyQZqk93aOXu7Lb3K1cKrriB1ONkQnTw64A== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 149.199.80.198) smtp.rcpttodomain=oktetlabs.ru smtp.mailfrom=xilinx.com; dmarc=pass (p=none sp=none pct=100) action=none header.from=xilinx.com; dkim=none (message not signed); arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=xilinx.onmicrosoft.com; s=selector2-xilinx-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=h5SKb2AZaGsOGz58T6btpIY0YFRUA87FKgRPh8gdotQ=; b=pfwy3MQNDWFSKtvvQ1118x6Hdqe+42NT403EeAsBY++EwPLeqagcWoUf165BnhEOr+LWhGJ17qyKp5fCOvYxnfIGE0y5S8wb9a4XW7W28RzzySBVIxDELG4gzgOdEe0hl63ik8jyaLTfm2lSlKprw2FQpHAuMTVL9NszdmTRjHU= Received: from BN0PR04CA0121.namprd04.prod.outlook.com (2603:10b6:408:ed::6) by DM8PR02MB7944.namprd02.prod.outlook.com (2603:10b6:8:15::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5612.16; Tue, 13 Sep 2022 09:31:23 +0000 Received: from BN1NAM02FT006.eop-nam02.prod.protection.outlook.com (2603:10b6:408:ed:cafe::d7) by BN0PR04CA0121.outlook.office365.com (2603:10b6:408:ed::6) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5612.12 via Frontend Transport; Tue, 13 Sep 2022 09:31:23 +0000 X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 149.199.80.198) smtp.mailfrom=xilinx.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=xilinx.com; Received-SPF: Pass (protection.outlook.com: domain of xilinx.com designates 149.199.80.198 as permitted sender) receiver=protection.outlook.com; client-ip=149.199.80.198; helo=xir-pvapexch02.xlnx.xilinx.com; pr=C Received: from xir-pvapexch02.xlnx.xilinx.com (149.199.80.198) by BN1NAM02FT006.mail.protection.outlook.com (10.13.2.125) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.20.5612.13 via Frontend Transport; Tue, 13 Sep 2022 09:31:21 +0000 Received: from xir-pvapexch01.xlnx.xilinx.com (172.21.17.15) by xir-pvapexch02.xlnx.xilinx.com (172.21.17.17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.24; Tue, 13 Sep 2022 10:31:08 +0100 Received: from smtp.xilinx.com (172.21.105.197) by xir-pvapexch01.xlnx.xilinx.com (172.21.17.15) with Microsoft SMTP Server id 15.1.2375.24 via Frontend Transport; Tue, 13 Sep 2022 10:31:08 +0100 Envelope-to: andrew.rybchenko@oktetlabs.ru, hpothula@marvell.com, thomas@monjalon.net, 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 Received: from [10.71.194.74] (port=26765) by smtp.xilinx.com with esmtp (Exim 4.90) (envelope-from ) id 1oY2G4-0004Zb-1j; Tue, 13 Sep 2022 10:31:08 +0100 Message-ID: Date: Tue, 13 Sep 2022 10:31:07 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.2.1 Subject: Re: [PATCH v3 1/3] ethdev: introduce pool sort capability Content-Language: en-US To: Andrew Rybchenko , Hanumanth Pothula , Thomas Monjalon CC: , , , , , , , , , , , References: <20220812172451.1208933-1-hpothula@marvell.com> <20220902070047.2812906-1-hpothula@marvell.com> From: Ferruh Yigit In-Reply-To: Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: BN1NAM02FT006:EE_|DM8PR02MB7944:EE_ X-MS-Office365-Filtering-Correlation-Id: 9694e053-5b04-44ac-cf69-08da956ab83c X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: c+jw5U6SmFSEg9iroKYvw8mKLW4vzTOzECDYMG0oMPl7zYsi2Ps+/xGHFDEMZQIbXx6wOOOXZHaQ8XFLWqcgObhmIxAZpJ+j1QeczLPvC1qAABPSQCkW3z49tP7AQHTA0r+9so3mvCby9Zbguo1GYTFYwdpiqa7iShFeC38I/+x9Yj3QIIi/+6sxPI9QJgJ1Ejk0yRzeLwnjSj7ZGpYHSgyz5qsJFIs1A4+kxOqmSXUL2uxWXP+CEigun4IVF0dd24gjjVEXVWAAP47uQmgRs0nYip87w5U3LQzKBdzt1CPuNjT7A9giUaJWFouyV2Qbo0tsyteArv5BrV3llEBon2hZdZ3K29ukYqCpKhSV6RoHBYSvty2SSxrrfTaU02BfmnuDGnubPOdwtxC5uZqrbg4o+6kOTzwrDKMvDnbS0gMKjJcfp2QkNUkd6q5Ei2MBcIuHcLnenXydtBx2VvarmqCLs3pUy9ixM6bjMncZQ3IzXYfY/TXgUjMd5PR4XlffkzPi9F1EXiKj0D59pTCeY6EcDrcmSr7/p++eoQNlnrjDPklG0GrfVnNnHpASMepEsJGBZqX8YfMp2zS/o3ECXmWKIO+RCMxpcHcnoFHvPq81o+UZNv3/PQdIUqiGL4T7jHheycsG8m14pmVJnGhgHzOccEgP3gxjZaD8mCyIyS7msDoMpRhcuO0+CnJoMH/CO+2JtdxomR1pE0187EqcGlPRFWyLH5WFKkeHbY3guci6987Zsk8MOwjRqg4rCMbZC8a7g5/0M5RutldYHaH3Yw+fpuT+OB6/CTk90HnXFdVmlp3YI+0ybhvVvDHQdLYUvHpckYqpmKZVwfsjkpWNvw== X-Forefront-Antispam-Report: CIP:149.199.80.198; CTRY:IE; LANG:en; SCL:1; SRV:; IPV:CAL; SFV:NSPM; H:xir-pvapexch02.xlnx.xilinx.com; PTR:unknown-80-198.xilinx.com; CAT:NONE; SFS:(13230022)(4636009)(346002)(39860400002)(376002)(136003)(396003)(451199015)(40470700004)(46966006)(36840700001)(70586007)(82740400003)(26005)(82310400005)(40460700003)(8676002)(2906002)(41300700001)(316002)(4326008)(31696002)(110136005)(83380400001)(9786002)(8936002)(53546011)(7416002)(44832011)(54906003)(31686004)(186003)(5660300002)(40480700001)(426003)(2616005)(478600001)(70206006)(336012)(47076005)(356005)(36860700001)(7636003)(36756003)(50156003)(43740500002); DIR:OUT; SFP:1101; X-OriginatorOrg: xilinx.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 13 Sep 2022 09:31:21.4692 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 9694e053-5b04-44ac-cf69-08da956ab83c X-MS-Exchange-CrossTenant-Id: 657af505-d5df-48d0-8300-c31994686c5c X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=657af505-d5df-48d0-8300-c31994686c5c; Ip=[149.199.80.198]; Helo=[xir-pvapexch02.xlnx.xilinx.com] X-MS-Exchange-CrossTenant-AuthSource: BN1NAM02FT006.eop-nam02.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM8PR02MB7944 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/13/2022 9:06 AM, Andrew Rybchenko wrote: > 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. > ack, and author already agreed to update it as 'MULTIPLE_POOL', perhaps should we say 'MULTIPLE_MEMPOOL' ? > 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] >