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 764AB42FA5; Mon, 31 Jul 2023 16:57:46 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id EAFAF40A89; Mon, 31 Jul 2023 16:57:45 +0200 (CEST) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-db5eur01on2077.outbound.protection.outlook.com [40.107.15.77]) by mails.dpdk.org (Postfix) with ESMTP id D36614067B for ; Mon, 31 Jul 2023 16:57:44 +0200 (CEST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=YHrmsIlrEGGzTsJy3jROJ3c2GIR5znZuBJY+QS4E252hXZyblHG05epX98wUn9lSOnawhL1wW1RLbb8HixUd2s/rZycwCT03z6gbg3vlkiXvui6HteM6vHjV+0BOnQVo0GmlnzRidC4zlR+r+nztxgJSa5QSPeklCPCvW8PGJK7NuPyJL1ckHYntQVQK9K0NFYP+1aMSZDlgepDUX1VrqzNUVgmmYjCCIDvQ0ZD533ZSJuZRZGUJmNQVCkBMY3F4f/Uw/+mXQDtKVrWgyreafm1/oXCPTJm8je2mPDYn8YnYjGCb4iZC2XpD69VXI2y3ND/CvNmVxVJYQydh2xepdg== 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=vg/0iRYDkxg3UyNdKKEUJj7cVw4K2zCeluIUpgqzups=; b=gJJPXT7F2zbiIeF6a+UIHLK+ILAygaOuVdjXI7vHUQTApJ91LSGGkeeI7JG4yYUy1v16N+8om5nyJM+71htb5bhSLi7RKvjCkeMKK7N07+PdcvWJ+VPIq2N795uZocEqd80UzGUq89tyAwCrbSp+VHMjqzFWudLSQKGhnFm/UxzFGx1NVVS1diLyYT6HgCI/VpQSAOktVZm3ATZcCcyaYwmnUJ3OPKgBDjZor90FL0Z4eANRYBGaD5poWcNpVhJbAKNF9k0HlZmZI6mqQBPMLdll/0m/+LN+hH7UOEXILQzgoX9Lcvvmm7/6RN3+UDEDrgu9HuuaBn9mb1woBqKd8Q== 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=vg/0iRYDkxg3UyNdKKEUJj7cVw4K2zCeluIUpgqzups=; b=+N/Mvre/zuHUSuJurhM6o0G7vyRuH2t9JQpv2WTIuRUd/Cq7A0Nkke0b2W0fX32y6Ay+g+JzK/nMLXhWQwqUIif0usEcHCfn8qYWgXpcKaMdyQnkrrnVqSMPsYRvnwGKvwfeM1fqFGBVWA2hMlyR/rXo3p/ijuZFvc824vyFP1M= Received: from AS4PR08MB7553.eurprd08.prod.outlook.com (2603:10a6:20b:4fb::6) by PR3PR08MB5708.eurprd08.prod.outlook.com (2603:10a6:102:84::9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6631.43; Mon, 31 Jul 2023 14:57:38 +0000 Received: from AS4PR08MB7553.eurprd08.prod.outlook.com ([fe80::a0ea:7b76:f9a6:e900]) by AS4PR08MB7553.eurprd08.prod.outlook.com ([fe80::a0ea:7b76:f9a6:e900%7]) with mapi id 15.20.6631.043; Mon, 31 Jul 2023 14:57:38 +0000 From: Dharmik Jayesh Thakkar To: =?iso-8859-1?Q?Morten_Br=F8rup?= , "thomas@monjalon.net" CC: "dev@dpdk.org" , Jerin Jacob , Bruce Richardson , Honnappa Nagarahalli , nd , Ruifeng Wang , Stephen Hemminger , "olivier.matz@6wind.com" , "andrew.rybchenko@oktetlabs.ru" , nd Subject: RE: [PATCH 0/1] mempool: implement index-based per core cache Thread-Topic: [PATCH 0/1] mempool: implement index-based per core cache Thread-Index: AQHX+RoFddxkmj6U9EuCivN1ihPFnKxCVwCAgBUmroCAAAPBgIAAJ3IAgAFLiACAAvK5gIAEpD4Ag0/lCwCAJvEbgIAAApKAgAAnHCA= Date: Mon, 31 Jul 2023 14:57:38 +0000 Message-ID: References: <20210930172735.2675627-1-dharmik.thakkar@arm.com> <20230706104302.4fd9807a@hermes.local> <12619560.VsHLxoZxqI@thomas> <98CBD80474FA8B44BF855DF32C47DC35D87AAF@smartserver.smartshare.dk> In-Reply-To: <98CBD80474FA8B44BF855DF32C47DC35D87AAF@smartserver.smartshare.dk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ts-tracking-id: F7FC9E3DB2A4464D9D8062F34AED7895.0 x-checkrecipientchecked: true authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=arm.com; x-ms-publictraffictype: Email x-ms-traffictypediagnostic: AS4PR08MB7553:EE_|PR3PR08MB5708:EE_ x-ms-office365-filtering-correlation-id: 9eaf8074-eda5-4f0f-580a-08db91d67b69 x-ld-processed: f34e5979-57d9-4aaa-ad4d-b122a662184d,ExtAddr nodisclaimer: true x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: RYN9LBtb5jD0oEmdKsGD7fkuomWx6zecqAwDx6YA3meoLA6iQR8YWrNIJIkZhKWGLWSp8QQ0vIS4x2K15frQ5P5Zygf/xWuVI2DdRq/QUu5qGW4qaumy69X8MRUZUTFTLe0XDUl2cR6YSpRIY1bfxmohTHB/aBLEnLj+D6SXssxoDgB+GE7PD01H31OvgeykqRNqqJ1oUvYzVAeSwSh9JAW/zP87XLdK8cLrAuYqSQMEqWqD2xgIPsuQ+Dohkp+FS/mWiP6xKQgCW5jt6yszkXdPyJU58jAFLxI5ZnodLH46S4xYqwkkBVXCOS9RkBQhHdA5s0pic6iHBMz2x3pp5GmiwNenoL72qIPBnbeNn7v4mQzxzDDCY1A9/Ubz8Ce13fH79ZR5jPZyrCbaB1FCaHrg+Y1Cpm8+u9Q/eq/gSNtqYx/6s9G04i4ChvubuVwZMoIy2My9Flz8OAp/+zQ7fuQn2K38Or3nLsjzdKOfX0YzCujnT1O+SMxGnK0t64uYFt4NCFqAYbsLmtNOz0DMVeq5tFzqk4NKW0hxWViZYUJckLIE5uZSJ0fzplQavtwn1FZHzUuC0Gk7awHkzYv3a33WgziI+DBgvWtpqX7AQ8XhziCADFQUTIRnHggijI4YcTVu+WLLJ7Jqg66W1p0m/w== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AS4PR08MB7553.eurprd08.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230028)(4636009)(39850400004)(136003)(366004)(376002)(396003)(346002)(451199021)(9686003)(966005)(7696005)(55016003)(53546011)(26005)(6506007)(83380400001)(186003)(66574015)(33656002)(76116006)(66946007)(66556008)(52536014)(41300700001)(122000001)(54906003)(110136005)(38070700005)(86362001)(66476007)(316002)(4326008)(5660300002)(64756008)(66446008)(8676002)(8936002)(38100700002)(2906002)(71200400001)(478600001)(30864003); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?iso-8859-1?Q?TDTEwd2qBdioI5h0dZEYW9HX4pSsBlXfMBmvdr5ZWkTGokctHjNJrMAD3M?= =?iso-8859-1?Q?+aQ7l0GZGeh6MWoq9UeQEIKwRvMKOW36dT9nF4o/kPbUVrry12VKqAc8mo?= =?iso-8859-1?Q?yx7Ez/GLanBRkeM2CzNsz9gqEVzvPHogE5hp8keRNa9vNKgr/rCXBnvHvO?= =?iso-8859-1?Q?oMw9NaZfUsgpdpHOZTd463etGIqe7chTvXZf4BrR7CAsSyIVPZ9dxcelU7?= =?iso-8859-1?Q?snYqlLwF6cP3dgJtLT96icpslZ7KkvxOtA1pIGpTmHIuMfRkd8Gi71z7LB?= =?iso-8859-1?Q?ydmY6Ig+kpyhTM1akig3b0mastzBgYJSN2V75cPeIg2efMN4kipId76GnX?= =?iso-8859-1?Q?0u050Pz5aBf4e4qyRx3/h92MD6PYBnsZPBt3gxNpQpaDuPoUaf2AqhVrqI?= =?iso-8859-1?Q?VwT6DNGhzPcYlUtw0Fa0P6AmeD3RJSR/oUkaSIz5BTDKZEWE+SgUSz8soU?= =?iso-8859-1?Q?vwtAo81rzWUcbSwTlpUVfcJAJhjDPbi2OV3XLJTME1eMmT9qyrRPWixq6v?= =?iso-8859-1?Q?JSA2eEJn+UubxNzjaEXt6SctqurVdPmZoPGmWxWlaZ/I5hpfk8BXp+oNmH?= =?iso-8859-1?Q?Epup7pZOJ4AG/bDdhLTK5syYPlOEaFnrh/dscDmZT3wX0p8UjPS2tyYzur?= =?iso-8859-1?Q?ud1k1jlJgaQ9QwWY6sDrBbMt2FP63mEzD2BHGTivAfNBVfY+731q4Fqo1r?= =?iso-8859-1?Q?LV5ly/A8cXT3SrGNwBdmjaqL6/kA+QHUB82iPi4aLmIDPliY1T6fGj0h3U?= =?iso-8859-1?Q?eW5aLu0qEsTWvXmSBelp2J3YrW3UuqbexVkH3LOy7xF5gtOYd5k1c3WZ5r?= =?iso-8859-1?Q?mO3K3Ys+KAVbkJfked2dwd3hI90QyxD2BTmqR5uaW9VOwxZZTNu82/UzVz?= =?iso-8859-1?Q?XoZng5T2fMXKEiYuaherB6M+qMoxHZ2HJYU863pwn9530YU/fwxfcsYQc4?= =?iso-8859-1?Q?j3D7FMpOMRwUegXvUrA5+JK6C80z72HenLTr3c3It901W76EI0nLs52mtu?= =?iso-8859-1?Q?dlswLl41wkS+g6kqr4JzFZCdJEWGUyBGiqy3S7IpPX9DaJPvrYurYJV6d6?= =?iso-8859-1?Q?cWBVHt8TK5mzYcsFlPbSSAFNU1HBp8yEkZPo1YKeDMTM+q+hHZ+vxx7j0n?= =?iso-8859-1?Q?wQl3/qJGjDPdNMQWjy3ZvJ5WcimRxQiPFUxWDZQIfoEJJ4qlaRQzg62HWS?= =?iso-8859-1?Q?0+WV478TcjvvZv3Mw3ZI3xgB5IPdsjhxm4TPYh4JGcLB6h5VRTN49S3oZp?= =?iso-8859-1?Q?KFzj0SckPQHynven8J+cK1X0RPoAxAYQOJTEV3wV4oPCQ53GhposZ47zQZ?= =?iso-8859-1?Q?mD1zM/kwnthrw2hnIYcZ2JIhLqCZ4E2Kyi0eAYbquNHgjmCaBePloNpTQ1?= =?iso-8859-1?Q?mVlbkMmRGVh9MqVhKKlPx++KvaOf5Nv/Pqou7mgf6reBgJ2J0IcZ8GzUkG?= =?iso-8859-1?Q?WQBqMOl0w1hvdP2MtwtnTUfB7znVSE5sVCYupoqOyDaz0xfbbVUqklciEZ?= =?iso-8859-1?Q?necp8E6B1TQCm63XV73jFYcLp6ieKH1rRuAMJHzG7S/DwQKnFmn+yV60Bv?= =?iso-8859-1?Q?POra2CScPSjk5EbB0yhSUROqVqz3qHM3cuV31DRzNsU67kfBbpOZB+t9wM?= =?iso-8859-1?Q?rnz7mM5DwUv4CRDdAP5W5Yr6RWO5mehIk6aHE8mskjyMZcDpiWTQNnEg?= =?iso-8859-1?Q?=3D=3D?= Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: AS4PR08MB7553.eurprd08.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 9eaf8074-eda5-4f0f-580a-08db91d67b69 X-MS-Exchange-CrossTenant-originalarrivaltime: 31 Jul 2023 14:57:38.2230 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: MEwFMT8zaV1SNCFy1jg1Bb4x/pXnzYb+v9bQSM86AJybBVJSoC6uFcwpZesOSL+/t9EXd7h5oe3m01LsRbTCjKWs/QD7d0/ZwXUbsTsSc+A= X-MS-Exchange-Transport-CrossTenantHeadersStamped: PR3PR08MB5708 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 > -----Original Message----- > From: Morten Br=F8rup > Sent: Monday, July 31, 2023 7:33 AM > To: thomas@monjalon.net; Dharmik Jayesh Thakkar > > Cc: dev@dpdk.org; Jerin Jacob ; Bruce Richardson > ; Honnappa Nagarahalli > ; nd ; Ruifeng Wang > ; Stephen Hemminger > ; olivier.matz@6wind.com; > andrew.rybchenko@oktetlabs.ru > Subject: RE: [PATCH 0/1] mempool: implement index-based per core cache > > > From: Thomas Monjalon [mailto:thomas@monjalon.net] > > Sent: Monday, 31 July 2023 14.24 > > > > The v2 was not sent, and Stephen dropped the patch from patchwork. > > > > Do we abandon this feature? > > +1, because I think that the zero-copy mempool cache access functions mak= e > this patch irrelevant. > > > Should I remove it from the roadmap? > > +1 V2 was sent (https://patches.dpdk.org/project/dpdk/patch/20220113053630.886= 638-1-dharmik.thakkar@arm.com/) However, it is not relevant anymore and can be dropped. Thank you! > > > > > > > 06/07/2023 19:43, Stephen Hemminger: > > > On Thu, 13 Jan 2022 05:31:18 +0000 > > > Dharmik Thakkar wrote: > > > > > > > Hi, > > > > > > > > Thank you for your valuable review comments and suggestions! > > > > > > > > I will be sending out a v2 in which I have increased the size of > > > > the > > mempool to 32GB by using division by sizeof(uintptr_t). > > > > However, I am seeing ~5% performance degradation with > > mempool_perf_autotest (for bulk size of 32) with this change > > > > when compared to the base performance. > > > > Earlier, without this change, I was seeing an improvement of ~13% > > > > compared > > to base performance. So, this is a significant degradation. > > > > I would appreciate your review comments on v2. > > > > > > > > Thank you! > > > > > > > > > On Jan 10, 2022, at 12:38 AM, Jerin Jacob > wrote: > > > > > > > > > > On Sat, Jan 8, 2022 at 3:07 PM Morten Br=F8rup > > > > > > > wrote: > > > > >> > > > > >>> From: Bruce Richardson [mailto:bruce.richardson@intel.com] > > > > >>> Sent: Friday, 7 January 2022 14.51 > > > > >>> > > > > >>> On Fri, Jan 07, 2022 at 12:29:23PM +0100, Morten Br=F8rup wrote= : > > > > >>>>> From: Bruce Richardson [mailto:bruce.richardson@intel.com] > > > > >>>>> Sent: Friday, 7 January 2022 12.16 > > > > >>>>> > > > > >>>>> On Sat, Dec 25, 2021 at 01:16:03AM +0100, Morten Br=F8rup wro= te: > > > > >>>>>>> From: Dharmik Thakkar [mailto:dharmik.thakkar@arm.com] > Sent: > > > > >>>>> Friday, 24 > > > > >>>>>>> December 2021 23.59 > > > > >>>>>>> > > > > >>>>>>> Current mempool per core cache implementation stores > > > > >>>>>>> pointers > > > > >>> to > > > > >>>>> mbufs > > > > >>>>>>> On 64b architectures, each pointer consumes 8B This patch > > > > >>> replaces > > > > >>>>> it > > > > >>>>>>> with index-based implementation, where in each buffer is > > > > >>> addressed > > > > >>>>> by > > > > >>>>>>> (pool base address + index) It reduces the amount of > > > > >>> memory/cache > > > > >>>>>>> required for per core cache > > > > >>>>>>> > > > > >>>>>>> L3Fwd performance testing reveals minor improvements in > > > > >>>>>>> the > > > > >>> cache > > > > >>>>>>> performance (L1 and L2 misses reduced by 0.60%) with no > > > > >>>>>>> change > > > > >>> in > > > > >>>>>>> throughput > > > > >>>>>>> > > > > >>>>>>> Micro-benchmarking the patch using mempool_perf_test shows > > > > >>>>> significant > > > > >>>>>>> improvement with majority of the test cases > > > > >>>>>>> > > > > >>>>>> > > > > >>>>>> I still think this is very interesting. And your > > > > >>>>>> performance > > > > >>> numbers > > > > >>>>> are > > > > >>>>>> looking good. > > > > >>>>>> > > > > >>>>>> However, it limits the size of a mempool to 4 GB. As > > > > >>>>>> previously discussed, the max mempool size can be increased > > > > >>>>>> by multiplying > > > > >>> the > > > > >>>>> index > > > > >>>>>> with a constant. > > > > >>>>>> > > > > >>>>>> I would suggest using sizeof(uintptr_t) as the constant > > > > >>> multiplier, > > > > >>>>> so > > > > >>>>>> the mempool can hold objects of any size divisible by > > > > >>>>> sizeof(uintptr_t). > > > > >>>>>> And it would be silly to use a mempool to hold objects > > > > >>>>>> smaller > > > > >>> than > > > > >>>>>> sizeof(uintptr_t). > > > > >>>>>> > > > > >>>>>> How does the performance look if you multiply the index by > > > > >>>>>> sizeof(uintptr_t)? > > > > >>>>>> > > > > >>>>> > > > > >>>>> Each mempool entry is cache aligned, so we can use that if > > > > >>>>> we want > > > > >>> a > > > > >>>>> bigger > > > > >>>>> multiplier. > > > > >>>> > > > > >>>> Thanks for chiming in, Bruce. > > > > >>>> > > > > >>>> Please also read this discussion about the multiplier: > > > > >>>> > > > http://inbox.dpdk.org/dev/CALBAE1PrQYyOG96f6ECeW1vPF3TOh1h7MZZULiY > 95z9 > > xjbRuyA@ > > mail.gmail.com/ > > > > >>>> > > > > >>> > > > > >>> I actually wondered after I had sent the email whether we had > > > > >>> indeed > > an > > > > >>> option to disable the cache alignment or not! Thanks for > > > > >>> pointing out that we do. This brings a couple additional > > > > >>> thoughts: > > > > >>> > > > > >>> * Using indexes for the cache should probably be a runtime > > > > >>> flag rather than a build-time one. > > > > >>> * It would seem reasonable to me to disallow use of the > > > > >>> indexed-cache flag and the non-cache aligned flag > > > > >>> simultaneously. > > > > >>> * On the offchance that that restriction is unacceptable, then > > > > >>> we can make things a little more complicated by doing a > > > > >>> runtime computation of the "index-shiftwidth" to use. > > > > >>> > > > > >>> Overall, I think defaulting to cacheline shiftwidth and > > > > >>> disallowing index-based addressing when using unaligned > > > > >>> buffers is simplest and easiest unless we can come up with a > > > > >>> valid usecase for needing more than that. > > > > >>> > > > > >>> /Bruce > > > > >> > > > > >> This feature is a performance optimization. > > > > >> > > > > >> With that in mind, it should not introduce function pointers or > > > > >> similar > > run-time checks or in the fast path, to determine what kind of cache > > to use per mempool. And if an index multiplier is implemented, it > > should be a compile time constant, probably something between > > sizeof(uintptr_t) or RTE_MEMPOOL_ALIGN (=3DRTE_CACHE_LINE_SIZE). > > > > >> > > > > >> The patch comes with a tradeoff between better performance and > > > > >> limited > > mempool size, and possibly some limitations regarding very small > > objects that are not cache line aligned to avoid wasting memory > > (RTE_MEMPOOL_POPULATE_F_ALIGN_OBJ). > > > > >> > > > > >> With no multiplier, the only tradeoff is that the mempool size > > > > >> is > > limited to 4 GB. > > > > >> > > > > >> If the multiplier is small (i.e. 8 bytes) the only tradeoff is > > > > >> that the > > mempool size is limited to 32 GB. (And a waste of memory for objects > > smaller than 8 byte; but I don't think anyone would use a mempool to > > hold objects smaller than 8 byte.) > > > > >> > > > > >> If the multiplier is larger (i.e. 64 bytes cache line size), > > > > >> the > > mempool size is instead limited to 256 GB, but > > RTE_MEMPOOL_POPULATE_F_ALIGN_OBJ has no effect. > > > > >> > > > > >> Note: 32 bit platforms have no benefit from this patch: The > > > > >> pointer > > already only uses 4 bytes, so replacing the pointer with a 4 byte > > index makes no difference. > > > > >> > > > > >> > > > > >> Since this feature is a performance optimization only, and > > > > >> doesn't > > provide any new features, I don't mind it being a compile time option. > > > > >> > > > > >> If this feature is a compile time option, and the mempool > > > > >> library is > > compiled with the large multiplier, then > > RTE_MEMPOOL_POPULATE_F_ALIGN_OBJ could be made undefined in the > public > > header file, so compilation of applications using the flag will fail. > > And rte_mempool_create() could > > RTE_ASSERT() that RTE_MEMPOOL_POPULATE_F_ALIGN_OBJ is not set in its > > flags parameter, or emit a warning about the flag being ignored. > > Obviously, > > rte_mempool_create() should also RTE_ASSERT() that the mempool is not > > larger than the library supports, possibly emitting a message that the > > mempool library should be built without this feature to support the lar= ger > mempool. > > > > >> > > > > >> Here is another thought: If only exotic applications use > > > > >> mempools > > larger than 32 GB, this would be a generally acceptable limit, and > > DPDK should use index-based cache as default, making the opposite > > (i.e. pointer-based > > cache) a compile time option instead. A similar decision was recently > > made for limiting the RTE_MAX_LCORE default. > > > > >> > > > > >> > > > > >> Although DPDK is moving away from compile time options in order > > > > >> to > > better support Linux distros, there should be a general exception for > > performance and memory optimizations. Otherwise, network appliance > > vendors will inherit the increasing amount of DPDK bloat, and we > > (network appliance > > vendors) will eventually be forced to fork DPDK to get rid of the > > bloat and achieve the goals originally intended by DPDK. > > > > > > > > > > Agree with Morten's view on this. > > > > > > > > > >> If anyone disagrees with the principle about a general > > > > >> exception for > > performance and memory optimizations, I would like to pass on the > > decision to the Techboard! > > > > >> > > > > > > NAK > > > Having compile time stuff like this means one side or the other is > > > not > > tested > > > by CI infrastructure. There never was sufficient justification, and > > > lots of > > objections. > > > Dropping the patch. > > > > > > > > > > > > > > IMPORTANT NOTICE: The contents of this email and any attachments are confid= ential and may also be privileged. If you are not the intended recipient, p= lease notify the sender immediately and do not disclose the contents to any= other person, use it for any purpose, or store or copy the information in = any medium. Thank you.