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 0D9A14591E; Fri, 6 Sep 2024 14:38:02 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id EDD4D4025D; Fri, 6 Sep 2024 14:38:01 +0200 (CEST) Received: from dkmailrelay1.smartsharesystems.com (smartserver.smartsharesystems.com [77.243.40.215]) by mails.dpdk.org (Postfix) with ESMTP id 315CD400D5 for ; Fri, 6 Sep 2024 14:38:00 +0200 (CEST) Received: from smartserver.smartsharesystems.com (smartserver.smartsharesys.local [192.168.4.10]) by dkmailrelay1.smartsharesystems.com (Postfix) with ESMTP id 0BBDB20CA1; Fri, 6 Sep 2024 14:38:00 +0200 (CEST) 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: [RFC PATCH v1 0/5] Adjust wording for NUMA vs. socket ID in DPDK Date: Fri, 6 Sep 2024 14:37:56 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Message-ID: <98CBD80474FA8B44BF855DF32C47DC35E9F6B6@smartserver.smartshare.dk> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [RFC PATCH v1 0/5] Adjust wording for NUMA vs. socket ID in DPDK Thread-Index: AdsAUpSGpxaDHumORO2XkqVx/pVhaQABhKVQ References: From: =?iso-8859-1?Q?Morten_Br=F8rup?= To: "Anatoly Burakov" , 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: Anatoly Burakov [mailto:anatoly.burakov@intel.com] > Sent: Friday, 6 September 2024 13.47 > To: dev@dpdk.org > Subject: [RFC PATCH v1 0/5] Adjust wording for NUMA vs. socket ID in = DPDK >=20 > While initially, DPDK has used the term "socket ID" to refer to = physical > package > ID, the last time DPDK read "physical_package_id" for socket ID was ~9 = years > ago, so it's been a while since we've actually switched over to using = the term > "socket" to mean "NUMA node". >=20 > This wasn't a problem before, as most systems had one NUMA node per = physical > socket. However, in the last few years, more and more systems have = multiple > NUMA > nodes per physical CPU socket. Since DPDK used NUMA nodes already, the > transition was pretty seamless, however now we're faced with a = situation when > most of our documentation still uses outdated terms, and our API is = ripe with > references to "sockets" when in actuality we mean "NUMA nodes". This = could be > a > source of confusion. >=20 > While completely renaming all of our API's would be a huge effort, = will take a > long time and arguably wouldn't even be worth the API breakages (given = that > this > mismatch between terminology and reality is implicitly understood by = most > people > working on DPDK, and so this isn't so much of a problem in practice), = we can > do > some tweaks around the edges and at least document this unfortunate = reality. >=20 > This patchset suggests the following changes: >=20 > - Update rte_socket/rte_lcore documentation to refer to NUMA nodes = rather than > sockets - Rename internal structures' fields to better reflect this = intention > - > Rename --socket-mem/--socket-limit flags to refer to NUMA rather than = sockets > - > Add internal API to get physical package ID [1] >=20 > The documentation is updated to refer to new EAL flags, but is = otherwise left > untouched, and instead the entry in "glossary" is amended to indicate = that > when > DPDK documentation refers to "sockets", it actually means "NUMA ID's". = As next > steps, we could rename all API parameters to refer to NUMA ID rather = than > socket > ID - this would not break neither API nor ABI, and instead would be a > documentation change in practice. >=20 > [1] This could be used to group lcores by physical package, see e.g. > discussion > under this patch: > https://patches.dpdk.org/project/dpdk/cover/20240827151014.201-1- > vipin.varghese@amd.com/ Thank you for cleaning this up, Anatoly. I would prefer to take one more step and also rename functions and = parameters, e.g. rte_socket_id() -> rte_numa_id(). For backwards compatibility, macros/functions with the old names can be = added.