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 86F4BA034C; Wed, 9 Nov 2022 18:58:05 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 22372400EF; Wed, 9 Nov 2022 18:58:05 +0100 (CET) Received: from EUR02-AM0-obe.outbound.protection.outlook.com (mail-am0eur02on2086.outbound.protection.outlook.com [40.107.247.86]) by mails.dpdk.org (Postfix) with ESMTP id 69BFB400D4 for ; Wed, 9 Nov 2022 18:58:03 +0100 (CET) ARC-Seal: i=2; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=pass; b=IdEu1syBOjC+R89n84KF/cDVr3qPbQkahwEWdNReh7VZv7bZqymYt65OubtPCl/e+WArn4YnzZR9RY4vzBMq0qqV7ehnQkcdrQSj55YjhZB225U5e12t/VnSCVmud/3E0p7UL3Q9SKeY1JXzDpa7EwnxF28sCJyQ1aLDJT0uj4yni3SJtuEp24l9ty2umg4LpGjj9sht8dijs9e46U1Hp3VGeGdZP8mu9x+SAR0bgU6xJdsr5M5+7CtiFkfX7iNJb1usjuVJCXwHbuAh73pyp57GiP8xa5pIDf6tZ6qVkxK8QVTPQ/63GEcYC++tbFCFo+nMzFyVvpLQHs+9SCLXDA== ARC-Message-Signature: i=2; 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=+eexH05YEnViybFH4qhCRXRvHFL1MhTe2GLS2pz21n4=; b=B75h5OoapNgHMTPEw6/IYkYNAKUUWBk4ZWD4GliFFwr72EjMQ9tB6DA3PR79mOjQJt/oOJ6Vnh7hdaPtyiRQDNx+FC4snfeorg+PSG4scuslS4fUaoulVRbWDxHd2wSUN3ElTGu6AlqO1dd7Lgxl4d34pMgWH2jj7GzPJo0cKZc+AB7VfUQkUEG5zx0jnRZ7idZPXW9tVIdqUT6HhBnufeHxbQTn0Lxa1zy2bT/d276MBcsoa+yvgGdSUA1JMR8eQxEMpiXsP8oEj7ITp1yx3AXHvuEcgIIzTyAWLkibHZXwPL10BGWzvZjy6Wmr7ivL53p4lObA2Kg2Y9Yph67eVA== ARC-Authentication-Results: i=2; mx.microsoft.com 1; spf=pass (sender ip is 63.35.35.123) smtp.rcpttodomain=dpdk.org smtp.mailfrom=arm.com; dmarc=pass (p=none sp=none pct=100) action=none header.from=arm.com; dkim=pass (signature was verified) header.d=armh.onmicrosoft.com; arc=pass (0 oda=1 ltdi=1 spf=[1,1,smtp.mailfrom=arm.com] dkim=[1,1,header.d=arm.com] dmarc=[1,1,header.from=arm.com]) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=+eexH05YEnViybFH4qhCRXRvHFL1MhTe2GLS2pz21n4=; b=mTdGzGqJ8PjLr9nIbHOBam0pHrBrBaRoMRmRSWEnIEl/V1uuL2p3ab8omFkrFAAEV4FxCoPPCDLgFlp2L6Z8helgL8ePvRQSMOhky5XlHbNEXv5L+uLNOLaqvRhoPX6M93vbitn/kSu7SAEc+ZMjPlUqSogiinXY7yxyucV2clM= Received: from AM5PR0402CA0014.eurprd04.prod.outlook.com (2603:10a6:203:90::24) by DBBPR08MB5947.eurprd08.prod.outlook.com (2603:10a6:10:207::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5813.12; Wed, 9 Nov 2022 17:57:59 +0000 Received: from VI1EUR03FT049.eop-EUR03.prod.protection.outlook.com (2603:10a6:203:90:cafe::f9) by AM5PR0402CA0014.outlook.office365.com (2603:10a6:203:90::24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5791.21 via Frontend Transport; Wed, 9 Nov 2022 17:57:59 +0000 X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 63.35.35.123) smtp.mailfrom=arm.com; dkim=pass (signature was verified) header.d=armh.onmicrosoft.com;dmarc=pass action=none header.from=arm.com; Received-SPF: Pass (protection.outlook.com: domain of arm.com designates 63.35.35.123 as permitted sender) receiver=protection.outlook.com; client-ip=63.35.35.123; helo=64aa7808-outbound-1.mta.getcheckrecipient.com; pr=C Received: from 64aa7808-outbound-1.mta.getcheckrecipient.com (63.35.35.123) by VI1EUR03FT049.mail.protection.outlook.com (100.127.144.168) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5813.12 via Frontend Transport; Wed, 9 Nov 2022 17:57:59 +0000 Received: ("Tessian outbound f394866f3f2b:v130"); Wed, 09 Nov 2022 17:57:58 +0000 X-CR-MTA-TID: 64aa7808 Received: from c9a1063cb118.1 by 64aa7808-outbound-1.mta.getcheckrecipient.com id EFF340F3-411B-4810-B83F-2D1D2900CCC6.1; Wed, 09 Nov 2022 17:57:53 +0000 Received: from EUR03-AM7-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id c9a1063cb118.1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Wed, 09 Nov 2022 17:57:53 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=km4WGXPMrkYep98V08BdWcbjZq5cptLDzt9CJ0+cIbTVaOg2G5ahpXT1GkyynL6S0Zfi6ZTNPb8vTqRjvTAj8jpeSTGhLh4VQiT9UspKA2oZ0mOtwXZw1HjJ7Vk88CWCx92/NN0jaokAVHzx84R5Upklgk4Ey5p4n0IjS+IVe8qO7B64VOBGce5gIr20RONEDJNVzbjSFnQcE2p9lswjJWARKHALiX9Sxp/EHljDbnbPTI9ga/KLasE94vgCQXGf8hBS5xfd+nZjSrs+Q2VE00jrHE5sLUaWTce57de0z5oYILOsxNEKqzgTG1NM/PeKxUE4r6T4oVXuzS5xctFbmg== 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=+eexH05YEnViybFH4qhCRXRvHFL1MhTe2GLS2pz21n4=; b=kynluVIywEPpzKea2N5HvG6Dp4EceWR9oZjIWseembVkSgYw3OK//wlxRKFbzcPBswTAZjXhJggNp8ovs40Uxsk5foMaO10AK/2w7U1PeZf5qxN47cqrjkHI5jj04FvCnxwRfKO5pW7dy+tS106JBfRIXQ046DNWkdDowW0byzGkjEYOVzldXgWicbKKi7sdPfOCpsR2XPcH2aOXeRhskI4r40qzLvzXeQfIREUG8HwV2cYh6clCjHwGrsRqtEIvs9LZCT5ZysvtC29kFL5mwrn4o2MntKJ4Q2h4/H64PNgY03FNkJ2PxTKp4XnU9b/6KrD1jd2oYDmTDW5QWdUE/w== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=arm.com; dmarc=pass action=none header.from=arm.com; dkim=pass header.d=arm.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=+eexH05YEnViybFH4qhCRXRvHFL1MhTe2GLS2pz21n4=; b=mTdGzGqJ8PjLr9nIbHOBam0pHrBrBaRoMRmRSWEnIEl/V1uuL2p3ab8omFkrFAAEV4FxCoPPCDLgFlp2L6Z8helgL8ePvRQSMOhky5XlHbNEXv5L+uLNOLaqvRhoPX6M93vbitn/kSu7SAEc+ZMjPlUqSogiinXY7yxyucV2clM= Received: from DBAPR08MB5814.eurprd08.prod.outlook.com (2603:10a6:10:1b1::6) by AM9PR08MB6209.eurprd08.prod.outlook.com (2603:10a6:20b:283::9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5813.12; Wed, 9 Nov 2022 17:57:51 +0000 Received: from DBAPR08MB5814.eurprd08.prod.outlook.com ([fe80::3fb6:b7b2:1e8d:11d6]) by DBAPR08MB5814.eurprd08.prod.outlook.com ([fe80::3fb6:b7b2:1e8d:11d6%9]) with mapi id 15.20.5813.012; Wed, 9 Nov 2022 17:57:51 +0000 From: Honnappa Nagarahalli To: =?iso-8859-1?Q?Morten_Br=F8rup?= , "dev@dpdk.org" , "olivier.matz@6wind.com" , "andrew.rybchenko@oktetlabs.ru" , Kamalakshitha Aligeri CC: nd , nd Subject: RE: [RFC] mempool: zero-copy cache put bulk Thread-Topic: [RFC] mempool: zero-copy cache put bulk Thread-Index: AdjxHCA/ROrKGJlPRZqF8NgKVJugtwAS1RvwABAiw0AArl49MA== Date: Wed, 9 Nov 2022 17:57:51 +0000 Message-ID: References: <98CBD80474FA8B44BF855DF32C47DC35D87489@smartserver.smartshare.dk> <98CBD80474FA8B44BF855DF32C47DC35D8748A@smartserver.smartshare.dk> In-Reply-To: <98CBD80474FA8B44BF855DF32C47DC35D8748A@smartserver.smartshare.dk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ts-tracking-id: A50B689D4CB71448B3B93A75819F39DB.0 x-checkrecipientchecked: true Authentication-Results-Original: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=arm.com; x-ms-traffictypediagnostic: DBAPR08MB5814:EE_|AM9PR08MB6209:EE_|VI1EUR03FT049:EE_|DBBPR08MB5947:EE_ X-MS-Office365-Filtering-Correlation-Id: 4e07ff74-6b89-492c-c9cf-08dac27bf032 x-checkrecipientrouted: true nodisclaimer: true X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam-Untrusted: BCL:0; X-Microsoft-Antispam-Message-Info-Original: zcfCJdfx7VwJRvGhAq938J5c8yprzXTYT6qFSuMl4igq6snXKnG3KgaBy62qaKJJzKVP72Xjv48D2il/NprNCZGWSOYRJyPEDElAhQwNTr9iT7WwovFMgrFsNyVGQR+KD64KhTOrJCg7sh+HBx0dKisR6doUScaa1P26ichG9bgGGTa80GAzV0mJ6jUfpUTrLLs46N8Z+V3hpXSMDriO0L14T3L7sUgFVnBYQO+8SsZ4sAZRApzkgdnOM27tTz2xdwQD4ROT97MJdfp/P8rZKHJJzyWokqNXQzB3mfqNAPmJPj2jTbpwmJDZEx5Th53N8Hih00LIVPRk6DYIo84B4gMW2l5jUZAtFV8vsdG2rCec82M2RXGHcwORfBX/612hLb0yzdt3s+91FJ4Whi2jK1446hgudrdiIqvKC/T86vOQqOTZ/p5POUCaWYR6c4iOXZR190OhNnoNWMka3KleQxCDxAUxMUdfSAXQ/3NL3xqZJhZOI5WRIl3cr97jZwXIyRwl8UH/5IFJK+E+ZEW999u5Iz3Q6O24z26jNlKxNk2yuGypt8KIlXAs9Kl8Ez5O8PkVcFdIu2DEIFE0wwsUEtLEGMHT29uovfYPeP4sF1IEMFZjS4I2+sNNZ1/mjYNulAGK3aQFp7VqDtQlEMExx/wVgvwsDu1QFPHj26ndlOenX4Vy4nosn7VkoCQ0bURYXIiym07dvof2CU6Ovj/p9QzOJ19LLou6aT1V/sTEW8kFQKRYvWRgxkFIkgexN9pgyprDbwzqluVbpFHHv1a5xHUJwp7M/hqiSmVy0oRCqbwqhbJqsqej0sHCtTlIzJOY9FuUrOmdmA8X8rH5sWr5dQ== X-Forefront-Antispam-Report-Untrusted: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DBAPR08MB5814.eurprd08.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230022)(4636009)(346002)(376002)(366004)(39860400002)(396003)(136003)(451199015)(7696005)(6506007)(186003)(2906002)(55016003)(5660300002)(122000001)(66574015)(9686003)(86362001)(66476007)(76116006)(66946007)(64756008)(66556008)(66446008)(8676002)(38100700002)(4326008)(83380400001)(8936002)(52536014)(26005)(41300700001)(66899015)(316002)(33656002)(71200400001)(966005)(478600001)(84970400001)(38070700005)(54906003)(110136005)(6636002); DIR:OUT; SFP:1101; Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM9PR08MB6209 Original-Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=arm.com; X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: VI1EUR03FT049.eop-EUR03.prod.protection.outlook.com X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id-Prvs: 210e207d-b00e-4e0c-573a-08dac27beb69 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: 0n3PNHc0K46Jp1cutO5bw70jDRLl0h1kO2xzrjDndPMbMiFfs3mOHTsZuscH66kCtFv0qxUMgA5ADDazwfMeZF6AD9x/2Up3Y5a9XA3+2PPhNUBJf5t/Z55TekfvC5dbdP0IoRuo+2OwCGN1NO57SOd7LMiaB0jEXAzlO9m8h1udbj0yleTQcy+ApZNPvD436MpVBxTixtAoIxcq8lslZlZnbXSuyQ5Y3i8n2ykfZNB4iXD5hwCPVgIlewjUQ5FOw+2/GMuzj0X+5drjIdAYOPZCOoeF+Jfh+Pq1AemN2rNqTxFtPGryGn8w9NNo4bzzeNZtOwn2xExdp1StlhCZb8UnwDQH+bop5MnBatMNYpZcD4c+YmVAD7PZavNqxsF0gQcYX3Flaq0l26/F4eoY/BGYqyINFvBpSUx+JO2L1ZkP0NIgaF7wOS1unfabilxSCrvqB3BadOhnJ7ifkk0s8fYlMdUstq+BmHvN/gUnZGJDecCzIg/GvCN6RtD3lKRY1dbggn21sDIuZJQMxk7+qM7XBngfXrufYqpMtsq0HK+9j91glj5x20Q9V1B18N1OiGY7yZIOnpWhVJu77kIou6GVb/4qU9Xp5n5m8OgR/LyB9oqMsh/wrV7/ZhoLETr89rPfRu+zB93WJm9RiKMf3pnKsb3iT8B3u56Nx/tUE9Gomrzst810xffUxigoIVglLE8edla8nG9K8IX+MJoKUKYZO3+NkXn3f8rzS36blN3xQbGRr/+8+HzrQIfyJ6+uA2WwdQF0KV73b5AlDmkxBR8IdPwRVeWvBqDUtJDgpqOa37Xl66Yinc0twomCvqbND/6//paztpiBA7uJGhLIrg== X-Forefront-Antispam-Report: CIP:63.35.35.123; CTRY:IE; LANG:en; SCL:1; SRV:; IPV:CAL; SFV:NSPM; H:64aa7808-outbound-1.mta.getcheckrecipient.com; PTR:ec2-63-35-35-123.eu-west-1.compute.amazonaws.com; CAT:NONE; SFS:(13230022)(4636009)(376002)(396003)(136003)(346002)(39860400002)(451199015)(40470700004)(46966006)(36840700001)(36860700001)(83380400001)(82310400005)(86362001)(336012)(966005)(70586007)(33656002)(356005)(82740400003)(81166007)(40480700001)(55016003)(478600001)(52536014)(5660300002)(8936002)(4326008)(41300700001)(316002)(8676002)(54906003)(110136005)(9686003)(6636002)(70206006)(7696005)(40460700003)(47076005)(186003)(26005)(66574015)(6506007)(2906002)(84970400001)(66899015); DIR:OUT; SFP:1101; X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 09 Nov 2022 17:57:59.1566 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 4e07ff74-6b89-492c-c9cf-08dac27bf032 X-MS-Exchange-CrossTenant-Id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=f34e5979-57d9-4aaa-ad4d-b122a662184d; Ip=[63.35.35.123]; Helo=[64aa7808-outbound-1.mta.getcheckrecipient.com] X-MS-Exchange-CrossTenant-AuthSource: VI1EUR03FT049.eop-EUR03.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DBBPR08MB5947 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 >=20 > > From: Honnappa Nagarahalli [mailto:Honnappa.Nagarahalli@arm.com] > > Sent: Sunday, 6 November 2022 00.11 > > > > + Akshitha, she is working on similar patch > > > > Few comments inline > > > > > From: Morten Br=F8rup > > > Sent: Saturday, November 5, 2022 8:40 AM > > > > > > Zero-copy access to the mempool cache is beneficial for PMD > > performance, > > > and must be provided by the mempool library to fix [Bug 1052] > > > without > > a > > > performance regression. > > > > > > [Bug 1052]: https://bugs.dpdk.org/show_bug.cgi?id=3D1052 > > > > > > > > > This RFC offers a conceptual zero-copy put function, where the > > application > > > promises to store some objects, and in return gets an address where > > to store > > > them. > > > > > > I would like some early feedback. > > > > > > Notes: > > > * Allowing the 'cache' parameter to be NULL, and getting it from the > > > mempool instead, was inspired by rte_mempool_cache_flush(). > > I am not sure why the 'cache' parameter is required for this API. This > > API should take the mem pool as the parameter. > > > > We have based our API on 'rte_mempool_do_generic_put' and removed > the > > 'cache' parameter. >=20 > I thoroughly considered omitting the 'cache' parameter, but included it f= or > two reasons: >=20 > 1. The function is a "mempool cache" function (i.e. primarily working on = the > mempool cache), not a "mempool" function. >=20 > So it is appropriate to have a pointer directly to the structure it is wo= rking on. > Following this through, I also made 'cache' the first parameter and 'mp' = the > second, like in rte_mempool_cache_flush(). I am wondering if the PMD should be aware of the cache or not. For ex: in t= he case of pipeline mode, the RX and TX side of the PMD are running on diff= erent cores. However, since the rte_mempool_cache_flush API is provided, may be that dec= ision is already done? Interestingly, rte_mempool_cache_flush is called by = just a single PMD. So, the question is, should we allow zero-copy only for per-core cache or f= or other cases as well. >=20 > 2. In most cases, the function only accesses the mempool structure in ord= er to > get the cache pointer. Skipping this step improves performance. >=20 > And since the cache is created along with the mempool itself (and thus ne= ver > changes for a mempool), it would be safe for the PMD to store the 'cache' > pointer along with the 'mp' pointer in the PMD's queue structure. Agreed >=20 > E.g. in the i40e PMD the i40e_rx_queue structure could include a "struct > rte_mempool_cache *cache" field, which could be used i40e_rxq_rearm() [1] > instead of "cache =3D rte_mempool_default_cache(rxq->mp, rte_lcore_id())"= . >=20 > [1] https://elixir.bootlin.com/dpdk/v22.11- > rc2/source/drivers/net/i40e/i40e_rxtx_vec_avx512.c#L31 >=20 > > This new API, on success, returns the pointer to memory where the > > objects are copied. On failure it returns NULL and the caller has to > > call 'rte_mempool_ops_enqueue_bulk'. Alternatively, the new API could > > do this as well and PMD does not need to do anything if it gets a NULL > > pointer. >=20 > Yes, we agree about these two details: >=20 > 1. The function should return a pointer, not an integer. > It would be a waste to use a another CPU register to convey a success/err= or > integer value, when the success/failure information is just as easily con= veyed > by the pointer return value (non-NULL/NULL), and rte_errno for various er= ror > values in the unlikely cases. >=20 > 2. The function should leave it up to the PMD what to do if direct access= to > the cache is unavailable. Just wondering about the advantage of this. I do not think PMD's have much = of a choice other than calling 'rte_mempool_ops_enqueue_bulk' >=20 > > > > We should think about providing similar API on the RX side to keep it > > symmetric. >=20 > I sent an RFC for that too: > http://inbox.dpdk.org/dev/98CBD80474FA8B44BF855DF32C47DC35D87488@ > smartserver.smartshare.dk/T/#u >=20 >=20 > > > > > * Asserting that the 'mp' parameter is not NULL is not done by other > > > functions, so I omitted it here too. > > > > > > NB: Please ignore formatting. Also, this code has not even been > > compile > > > tested. > > We are little bit ahead, tested the changes with i40e PF PMD, wrote > > unit test cases, going through internal review, will send out RFC on > > Monday >=20 > Sounds good. Looking forward to review. >=20 > > > > > > > > /** > > > * Promise to put objects in a mempool via zero-copy access to a > > user-owned > > > mempool cache. > > > * > > > * @param cache > > > * A pointer to the mempool cache. > > > * @param mp > > > * A pointer to the mempool. > > > * @param n > > > * The number of objects to be put in the mempool cache. > > > * @return > > > * The pointer to where to put the objects in the mempool cache. > > > * NULL on error > > > * with rte_errno set appropriately. > > > */ > > > static __rte_always_inline void * > > > rte_mempool_cache_put_bulk_promise(struct rte_mempool_cache > *cache, > > > struct rte_mempool *mp, > > > unsigned int n) > > > { > > > void **cache_objs; > > > > > > if (cache =3D=3D NULL) > > > cache =3D rte_mempool_default_cache(mp, rte_lcore_id()); Any reason we need this? If we are expecting the PMD to store the pointer t= o cache and a NULL is passed, it would mean it is a mempool with no per-cor= e cache? We could also leave the NULL check to the PMD. > > > if (cache =3D=3D NULL) { > > > rte_errno =3D EINVAL; > > > return NULL; > > > } > > > > > > rte_mempool_trace_cache_put_bulk_promise(cache, mp, n); > > > > > > /* The request itself is too big for the cache */ > > > if (unlikely(n > cache->flushthresh)) { > > > rte_errno =3D EINVAL; > > > return NULL; > > > } > > > > > > /* > > > * The cache follows the following algorithm: > > > * 1. If the objects cannot be added to the cache without > > crossing > > > * the flush threshold, flush the cache to the backend. > > > * 2. Add the objects to the cache. > > > */ > > > > > > if (cache->len + n <=3D cache->flushthresh) { > > > cache_objs =3D &cache->objs[cache->len]; > > > cache->len +=3D n; > > > } else { > > > cache_objs =3D &cache->objs[0]; > > > rte_mempool_ops_enqueue_bulk(mp, cache_objs, cache->len); > > > cache->len =3D n; > > > } > > > > > > RTE_MEMPOOL_CACHE_STAT_ADD(cache, put_bulk, 1); > > > RTE_MEMPOOL_CACHE_STAT_ADD(cache, put_objs, n); These are new stats. Do these break ABI compatibility (though these are und= er DEBUG flag)? > > > > > > return cache_objs; > > > } > > > > > > > > > Med venlig hilsen / Kind regards, > > > -Morten Br=F8rup > > > > >