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 EA3474557F; Fri, 6 Sep 2024 15:17:49 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id D3F914025D; Fri, 6 Sep 2024 15:17:49 +0200 (CEST) Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.13]) by mails.dpdk.org (Postfix) with ESMTP id B2A94400D5 for ; Fri, 6 Sep 2024 15:17:48 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1725628669; x=1757164669; h=message-id:date:subject:to:cc:references:from: in-reply-to:content-transfer-encoding:mime-version; bh=12fGz9d0xDgL0FpbXmFqyFwD2TBNMBhxjXcDvKmm+nU=; b=MtZmwXGJAYobLg2r7fkG2kMzH/w40vDQIvpj+XkHDaiZwI2VHpKKwQz6 MtHoIGgoCAci9mL2b2M/LVkNr7zqjbMVr8pDqxPL9OS9bxB2JwziTDxjs c7bmSWcYyS3TqR4QsD2exOZ22iBsAJR//m1yhAhMtmmB/6YpfP4u0GYit 4u37854ZDN5w600r49krwnLeHVchu6u21ccEf3jPcuoOBRvnCxMnhLQNN hADQz1z5XpEjyyuVnpyhorXKXbMu24g65XsqNXXCoLwo53qhQvww6ck2v WB2yPqE8b/IYMcc/3T4aXkKgXfXrrOA5NrzmwqfKOTLV8mOV+8zS6tegJ A==; X-CSE-ConnectionGUID: sKFTb7j/SJK9EC9sIyWJwQ== X-CSE-MsgGUID: vDFElql9SPG0dPxbBWCSnQ== X-IronPort-AV: E=McAfee;i="6700,10204,11187"; a="27313267" X-IronPort-AV: E=Sophos;i="6.10,207,1719903600"; d="scan'208";a="27313267" Received: from fmviesa003.fm.intel.com ([10.60.135.143]) by fmvoesa107.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 06 Sep 2024 06:17:48 -0700 X-CSE-ConnectionGUID: r3ak/6EnSqWENVK28nbAXg== X-CSE-MsgGUID: VRNAZOHnQQeGCa2xQXu+uQ== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.10,207,1719903600"; d="scan'208";a="70091110" Received: from fmsmsx601.amr.corp.intel.com ([10.18.126.81]) by fmviesa003.fm.intel.com with ESMTP/TLS/AES256-GCM-SHA384; 06 Sep 2024 06:17:46 -0700 Received: from fmsmsx610.amr.corp.intel.com (10.18.126.90) by fmsmsx601.amr.corp.intel.com (10.18.126.81) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Fri, 6 Sep 2024 06:17:46 -0700 Received: from FMSEDG603.ED.cps.intel.com (10.1.192.133) by fmsmsx610.amr.corp.intel.com (10.18.126.90) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39 via Frontend Transport; Fri, 6 Sep 2024 06:17:46 -0700 Received: from NAM04-DM6-obe.outbound.protection.outlook.com (104.47.73.46) by edgegateway.intel.com (192.55.55.68) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2507.39; Fri, 6 Sep 2024 06:17:46 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=JzMRZ+WYGasDhcpKD7GvLJzNh03loSigA1QgXqImZcIkh9epqOLnfj3GMpk38h9nV1CJYWVYzJSpd8KpvSiLIEgNLuh1N2pC1ANanrZGiZGGZM4MBEFP4y65rJTxKF5DyGl16oZBEDlmKAl5sYbRuJ+jHnl1KtfIn1rsh+6PYuvXWBk+cHSN5UJfhlxDj8gUUXFOn3+ekeUMJs0CGbGEZ19Ue0e6VbdbHHCmXpEacAVXRK1dh2y96bbYtz4nCV11/VQ0Gew4i/16PbAoASTzvm8khb6KHyRvJPWgwOZfuhkZC083qpHeXctNaJhQR09nouStNKWDvsgz/O8MmU5Bbg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; 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=yW9ny5JGkbDn6NTuiZ27PsvxrWcSQMpkfwLExj5Z1Sw=; b=q/Q4qWbP5D6qZhksiHnU9Nlrs3XBsG+rtr1AkRMuKwfMv5bJKppFyGrABSfum14LEFeh5SWpRzZTivbWS8j/Jmr+r9VaoM2vk3Desr0qOQUyJnDMn+xCivGKLtdGSss+2kE5j96moNPebgO8zIrhJAPvAYJqr69ix4HgXJZsxJxVbeiI16rJ0aaL9+fPLrgPnuNIJzsNqbmaJqPvgvHmApn82e22YV8c0aQXAcUbhk9GGRr5D4re8B8Vr/Hf9Jnd9u192zfvmUqW8mjIW5S/QuoUYhWqX/6OgtK4j+sUlGxcwqhJZiTRLeYy62OBVau/9xevBsFuZjU27vH0T9eZ5w== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=intel.com; dmarc=pass action=none header.from=intel.com; dkim=pass header.d=intel.com; arc=none Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=intel.com; Received: from DM4PR11MB6502.namprd11.prod.outlook.com (2603:10b6:8:89::7) by MN2PR11MB4646.namprd11.prod.outlook.com (2603:10b6:208:264::8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7918.31; Fri, 6 Sep 2024 13:17:43 +0000 Received: from DM4PR11MB6502.namprd11.prod.outlook.com ([fe80::21e4:2d98:c498:2d7a]) by DM4PR11MB6502.namprd11.prod.outlook.com ([fe80::21e4:2d98:c498:2d7a%4]) with mapi id 15.20.7918.024; Fri, 6 Sep 2024 13:17:43 +0000 Message-ID: <069408ae-c468-475c-a12c-c660426b643e@intel.com> Date: Fri, 6 Sep 2024 15:17:36 +0200 User-Agent: Mozilla Thunderbird Subject: Re: [RFC PATCH v1 0/5] Adjust wording for NUMA vs. socket ID in DPDK To: Bruce Richardson , =?UTF-8?Q?Morten_Br=C3=B8rup?= CC: References: <98CBD80474FA8B44BF855DF32C47DC35E9F6B6@smartserver.smartshare.dk> <84df3e19-f6cb-4a32-9360-a4384ce4c2ac@intel.com> <98CBD80474FA8B44BF855DF32C47DC35E9F6B7@smartserver.smartshare.dk> Content-Language: en-US From: "Burakov, Anatoly" In-Reply-To: Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit X-ClientProxiedBy: DU7P194CA0023.EURP194.PROD.OUTLOOK.COM (2603:10a6:10:553::14) To DM4PR11MB6502.namprd11.prod.outlook.com (2603:10b6:8:89::7) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: DM4PR11MB6502:EE_|MN2PR11MB4646:EE_ X-MS-Office365-Filtering-Correlation-Id: 89f73ad8-40fa-4a42-10f2-08dcce764a7b X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|1800799024|376014|366016; X-Microsoft-Antispam-Message-Info: =?utf-8?B?WEcraW9MNHIvOGdhTTVjanpiUjhnSyt3OWFTVkJUS0ZaWnhiRi80R1MyNkRm?= =?utf-8?B?SjVDQzdMWmo2WlViQWUxdWtKZUU1TXZ4WVZqU0dneWJ5MjZ5U1FWemkzVXhX?= =?utf-8?B?ZFpyTlJwZmlOM21hd0FXUjVTUUJ3YVB5QXhEWkdWU3kxY0pRSzUwK1RpVWtY?= =?utf-8?B?cXZJWmRzUW9HVytQNXFGSXNwc2dEM0dqd3VtL0Y2UVpGK1VhTnFEWjI4V01T?= =?utf-8?B?WGxueEFxVmZNSTlxYzVwOENEZk43a202SGtvTFduME11cWcyQmVoKzYwMnZk?= =?utf-8?B?bjBoWjB1ZlFtb0VuT2V2U25YdGhyekEzNHh3ZXVYSThiT3NMZjRiQzgySjUy?= =?utf-8?B?WXg3dElVVFJoNTVGVDF5alNORnRreEdlMkZabGU0aWhwdHhqb1ZiNlpEc0xP?= =?utf-8?B?SVdPblNISXA0UXFWdDUrR0hTQjlqQVRFVnNZbzl4aWs0bXdoUWVJQ21jeHpX?= =?utf-8?B?a29tcFdZRFllbVNiMjNBSDR4cDZkUCtrV0dWTjZuc01HTkFydnlSalRmZGEv?= =?utf-8?B?ZEZYRFh6RVJzb050TnRVT1RxaWJtZ244SVA4di96Q1ZzWEk5M3ZZTkFMSzF6?= =?utf-8?B?NU0vbmd2a01jMXBVSnk4d2RJS3ZQTHdJMTZzSGtHdFlybjlSa1AzN2lXUTRS?= =?utf-8?B?SmpwbENwNmhyTlJxWEZxaEhHWlo1ZGZIcUFtQmJZV2Y3b255Yk9YWTBMcVJ4?= =?utf-8?B?ZWZ4aDhHMkVZTlg4TWJiYjlEMndIYWEyb1ZDWDErWDlFbzIyUENwa3NYZFpr?= =?utf-8?B?Mkd1YlQ1Y1dvakhNWC9PQjBqWlJjS0o4dzNQMmtzNmZFeGhqTFhSQURQNHNJ?= =?utf-8?B?S2QwRS9MMWdQc3Jtb3VvMnluMVJONkhPLzF2THVNT0pSWEpwNlU0Tm5GK01a?= =?utf-8?B?ankwODQwVHQ1djQ1Z21sQXpTS2k1QkpqU3A5WnhNNUhMdFRPWThEWmxqMTFX?= =?utf-8?B?d0xwWDI4bjNKK2lnZy9mYWk3Y2U0Z2JNYXdGQnJHQnlkY1F2bk9iNWRWMzFt?= =?utf-8?B?R3JLVWtGQVNMR2pERklkdkE3dEs3eEh1TXJFM25zUDY3ZkZobTNRQ2JlSWt4?= =?utf-8?B?bWQ5NEgvMVZ4clJ6TXhRd2FQbDFwR0NYTkZ5NzRqZmJDQSsrRW5CQzd3MEZB?= =?utf-8?B?eXMySjlUb3NMRkx1bHFIak1oQ3JhdnFYVFM5NmtVanNIaXlocDdRRGlrUW5W?= =?utf-8?B?Uk9BUWsydTA1N1NvR3BTeHNqNXREZXY3MzVrV3ZOTXhaa0t1a3V1SFNhc2Ri?= =?utf-8?B?bVJnVlFmWm82dzFtSXBjV3NDQzUyT1orQ280dWp1S1o0WDZteXRPR2hKNVFI?= =?utf-8?B?MFBoelRTdDl3bS9qZmNWZmtIZGpJUjh0dnZrN00wdTJVaWI4aU1TR0NvMFAv?= =?utf-8?B?ZElZWVIzd3MxZTFETmdDd0RKWURZVDBBRDUwWnJQeDF4YnNuNUtYbld3dElI?= =?utf-8?B?YzJjb3JjK3FhNUM3anN1dzR1enA1bytEa0t3cDU3UGlJakk4N2VGQWI0N251?= =?utf-8?B?U1M5cFl5SThKR0pCODkvd2VvdW5WSlBUdFNIZXY2OXZ5R3JKM1E1bUtKcmU2?= =?utf-8?B?WTF4YWlBcjNialVETWpkWGZLT3lTNHhQRVh4WWxGMkl2aWk5Y1Q4QmtXWTZi?= =?utf-8?B?dSs2U2ZkdE51b28zTEl5MkZZTE1UVUtUYkFieDNIRy9KZjVxTmxjblR2U25R?= =?utf-8?B?a1I4RTJMcmlycGg2cTF4aG1MU0NSS1cwblltYlBTTnVkTzRKQlhLa241TGdQ?= =?utf-8?B?YnZSY2JXbzByNXIxOXM1Vkw5V3Brb3g0YVRiSmxWbGVONWxkT2lpRG1iMmxK?= =?utf-8?Q?7zARsB8lPtbQWGGflzuE7ubq5NKtAdoKt+Foo=3D?= X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM4PR11MB6502.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230040)(1800799024)(376014)(366016); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?bVFmSkcwb3RQa1FlMUNWNnk3TFdGa0tLVUtZOVZwRXc0YmhvbzdlMVExQzNE?= =?utf-8?B?ZVBZaEplMnV3QUtKMVFHWmlsYUJoR003QkJvY0RIQU00NkhMa0tvVFRFQnR6?= =?utf-8?B?L3haZ3FIYjg5OVdsamhQSWpOTXZGazR5YWhNdjNCamc2cHBNNlJmcVFDclJF?= =?utf-8?B?YU5OMCt1Z3BGUk9TdzhkcWRvZEZVMkNYZHNwM0FGYmU4ZDlVWHJNeTdreENy?= =?utf-8?B?TlBVTmZPeG03eVIxL2I3VXZwcThTdlBCUVBzM1VRUkttTUZ4dGFvdWY4Ykgw?= =?utf-8?B?K1F0Qm53dFlHWjUzSTRpdUU1V3NLNGlGV0NZSXBtU2RlaGpxUGcwbXlyTmV1?= =?utf-8?B?M0xLaHJQc2tWM1Rjdmx5RkRZbFFBSER4UVZHUk5yeHZ2Q1NaNlIxREIyWmY2?= =?utf-8?B?TWJpVUc1S3VKVGxlK21qenRKZlluZytPQWZCL2ljN3JMTCswLzIyclhVeS9t?= =?utf-8?B?M242WGhkTjQyd1RIYmJQRllEZHByVzY5R2R4Nnh2SUE2SnJwUVlrNlNEcFJs?= =?utf-8?B?eHd4c281VUpZR1RZMzRWN2cxKzEzejg5Slo4MTNXS09iaWFlM1puN2NpaG9r?= =?utf-8?B?RHVaQWZVK0lTdnFGRWl3V1F2Vm54T0tWL1VzbHRzY1BsTFRlaU1zZVNORTFK?= =?utf-8?B?UGNlTFo3MzdXZTdoSVdlQWVsRno1bWFsM0c2VGVCWFVTdng2dE14amYrMk5K?= =?utf-8?B?TTR5NG1NbXRnZlh2TXh5LzJPb2ozUW5tUXhzWnNuMXUydmRBelNzUlVTSzF6?= =?utf-8?B?OWFobXlkQ1JGaGJnZXA3WEZYQWppVjFOM1l1K20rSDZRbktHYTVNQThzZ1Yv?= =?utf-8?B?d1dvR2ZGTm9KOUpCdGRndFdNSU1YQ1FVOWRVQzNhMFBlcXE3Y21nTjViK2Zt?= =?utf-8?B?QUlHRHNEL3M0MXd5NVRzYXhRcVhTZjVoaWszWUI3d2tuNDh6MzU2OXk0RDZW?= =?utf-8?B?cFlRQzZXc1NQZ2NNblR6ZjU1UzF6UkV5U1hiQ1QyUS9jRnlxSGV1S3ZjdTZ1?= =?utf-8?B?ZjZqdURZQk1MVllqbDRGTFBHUEkvVFVtZy9iZTRZaGkzcW5pTmlnYkppNWdI?= =?utf-8?B?aTFNNXY0WW9mQ3h0L1BaMUdJMFQyQkQvN2RrMHozQXdtaGlzNUF2Y1ZHNmZR?= =?utf-8?B?Vmw1YjJOMC8zaXpRR1pJTkJYaGtxK1J2SFpzWlpGOXJsdFk1V1BlT1hyQUc0?= =?utf-8?B?NnU0STc1aE1TWituK0lRaTdDWVBRNG44OHgwdEVNOFgybnllS0llOTBPUW9s?= =?utf-8?B?NTFnZlYvUFJIN1VOeGdhM3Jpa0k1NzdyWU1YSTlYVU1yY0ZsYko5REdsWk0z?= =?utf-8?B?STFNTkRsVmRtRHZEaHlMMTdSSjZZRy81dDcvN2VUVGRPNHk5R0Urd3dVZjlL?= =?utf-8?B?N2VOcy8rOGw0NVZTTUI3RktDZTFweDd1YVBHekpLQWVkV3ZzTHRaaXR3bGFN?= =?utf-8?B?SVo2NSt0YjhqQ1EyblZXMVpCdmZlc1dSRGM5Mmh2YktVUnpGVFhDK0VkQzV5?= =?utf-8?B?U2JNN1phMVFQSEM0d0E3OWlxN0g1OVduWTQzYUVHeHJWUm5xWkpTbGNPYitI?= =?utf-8?B?V1BleG96anhDTDZ4RWhRNkdZL0lsYlhhNzBjeEMyV1ZhZkRKL29JS2NManZh?= =?utf-8?B?Ri9Ld2NiTUpVMmlrUHQwZU5IeWdKcEtzVDQxeTM5NUNmY3VKOVMzdGEvSTU3?= =?utf-8?B?emNTYWNZUVlKakdpRTczZ2h6bmtXUEFrQUxuaVRWcnMxRTBIem90U0tUTDF6?= =?utf-8?B?RXdxVnBXTFdmTHN2R3J0WmtkQ1M2MEVodnZ2L3lvYUg2M2x0ZnhUNU0yNkZG?= =?utf-8?B?Sldoenc3R2tDUHIycXhkUHJqeWZvOGVXSm9WdTVUQzdVWFlvWHRnc1FwSWwx?= =?utf-8?B?c3dBRXdJWjBFYTc1eno2RUdvM05PVktRUEdETityYis0bThTNnJpTDVqdjRm?= =?utf-8?B?S1Y3TkJSRnZocWNZV01OdTBFYVFYZ3h5d1lqaDd6K2UyNHBjTWdSSE1zSWRC?= =?utf-8?B?M3dPemVjWWpQMVBtalcxWS9CaDRSOWk3WmYydlhmcmlicGp2UEZEbThHeXg0?= =?utf-8?B?N3BNWGM0TGZPdkdTTCtRL1NYclpRajZDcVVKai83RWdaR0tvSlREUVhwR1V3?= =?utf-8?B?TzRQelJ2L0hnUGdtV0xvdUNMRFcvSjY5RVBVYkFnbGxJTWFJaTV0NHlTZWlS?= =?utf-8?B?d2c9PQ==?= X-MS-Exchange-CrossTenant-Network-Message-Id: 89f73ad8-40fa-4a42-10f2-08dcce764a7b X-MS-Exchange-CrossTenant-AuthSource: DM4PR11MB6502.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 06 Sep 2024 13:17:43.2260 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 46c98d88-e344-4ed4-8496-4ed7712e255d X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: z+8m5FrfDXAlTZFz/srrSNovCbPPjbhPglRdAL6x490O0c3miqPJpu9IUTnmR7WppKzb3RsiIvFDAtGMPnm9JBqFEet0ANDgTQKLgh3xHgE= X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB4646 X-OriginatorOrg: intel.com 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/6/2024 3:07 PM, Bruce Richardson wrote: > On Fri, Sep 06, 2024 at 03:02:53PM +0200, Morten Brørup wrote: >>> From: Burakov, Anatoly [mailto:anatoly.burakov@intel.com] >>> Sent: Friday, 6 September 2024 14.46 >>> >>> On 9/6/2024 2:37 PM, Morten Brørup wrote: >>>>> 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 >>>>> >>>>> 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". >>>>> >>>>> 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. >>>>> >>>>> 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. >>>>> >>>>> This patchset suggests the following changes: >>>>> >>>>> - 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] >>>>> >>>>> 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. >>>>> >>>>> [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. >>>> >>> >>> I don't think we can do such changes without deprecation notices, but >>> it's a good candidate for next release. >> >> Perhaps we can keep ABI compatibility by adding wrapper functions with the old names/parameters, which simply call the same functions with the new names/parameters. >> >> The Devil is in the details, and I haven't looked deeply into this. So take with a grain of salt. >> >>> >>> I have thought about including parameter renames in this patchset, but >>> for now I decided against doing so. I can certainly include this in the >>> next revision if that's something community is willing to accept. >> >> I agree with your decision on this. Renaming the parameters without renaming the functions could be confusing. >> > > I actually wonder if that is true. If we are simply renaming the parameters > without: > a) changing their types > b) changing the function behaviour > then it is neither an API nor an ABI break. If we were to do so, it would > be like changing a comment, since the actual parameter name is purely a > convenience to hint to the user what the value being passed actually does. > > That only applies for function parameters though. For any defines or macros > that need renaming, then we are into API break territory and we would want > backward compatible versions of same. > To be clear, I was referring to the former rather than the latter; renaming public API function parameters/structure fields can be done relatively easily and won't break anything. If there is consensus on going further than I have with this patchset, I can certainly do so. -- Thanks, Anatoly