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 71370A034C; Fri, 21 Jan 2022 09:59:53 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id E3B6D42733; Fri, 21 Jan 2022 09:59:52 +0100 (CET) Received: from smartserver.smartsharesystems.com (smartserver.smartsharesystems.com [77.243.40.215]) by mails.dpdk.org (Postfix) with ESMTP id 42D9C40042 for ; Fri, 21 Jan 2022 09:59:51 +0100 (CET) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: [RFC] mempool: cache preparation X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Fri, 21 Jan 2022 09:59:50 +0100 Message-ID: <98CBD80474FA8B44BF855DF32C47DC35D86E1A@smartserver.smartshare.dk> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [RFC] mempool: cache preparation Thread-Index: AdgOpT9GczmQt2GwSFu4FwqncsOxNA== From: =?iso-8859-1?Q?Morten_Br=F8rup?= To: "Olivier Matz" , "Andrew Rybchenko" , "Beilei Xing" , "Jingjing Wu" , "Qiming Yang" , "Qi Zhang" , "Honnappa Nagarahalli" , "Thomas Monjalon" , "Bruce Richardson" 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 Some drivers bypass the mbuf/mempool library functions, to manipulate = the mempool cache directly for improved performance. Specifically, the AVX512 implementation of some of the Intel PMDs copy = an array of objects from the cache to a field in an array of some = structure, i.e. it is not a 1:1 memcpy. This method avoids having to = copy the array of pointers into a temporary array before copying them = into the fields of the target array, and thus improves performance and = reduces CPU cache pollution. For such purposes, the mempool API could provide functions to prepare = the mempool cache for a direct access operation, and commit the = transaction: 1. Prepare the cache for getting N objects directly from the objs array. = This function returns the address of the position in the cache array, = from where the objects can be read, or NULL if failed. 2. Commit after getting the N objects. 3. Prepare the cache for putting N objects directly into the objs array. = This function returns the address of the position in the cache array, to = where the objects can be written, or NULL if failed. 4. Commit after putting the N objects. The functions only need to support getting/putting exactly N objects; = i.e. the "prepare" functions do not need return a value indicating some = number less than N is available. Likewise, the "commit" functions do not = need to support any N other than the N in the preceding "prepare" = function. This API extension would provide a clean interface to directly access = the mempool cache with high performance, so copy-pasting the mempool's = cache handling logic can be avoided, and bugs like [1] would not = survive. Would this be useful? [1]: https://bugs.dpdk.org/show_bug.cgi?id=3D923 Med venlig hilsen / Kind regards, -Morten Br=F8rup