Adjust wording for NUMA vs. socket ID in DPDK

Currently, --socket-mem and --socket-limit EAL flags effectively refer to NUMA nodes, not CPU sockets. Update the flag names to reflect this. Old flag names are still supported for backward compatibility.

Signed-off-by Anatoly Burakov <[email protected]>

---

Notes:
Technically, this is a user-facing change and so would require a deprecation notice. We can do it the other way around, and add support for --numa-mem/--numa-limit but do not expose it in documentation yet, and instead add a deprecation notice for next release. However, since old flags are kept for compatibility, nothing will break as a result of merging this series even if we didn't announce this change in advance. I'm open to feedback on how to best do this change.

lib/eal/linux/eal.c +2 -2

index cf174aeaa3..591028f641 100644
@@ -443,8 +443,8 @@ eal_usage(const char *prgname)
 	printf("\nUsage: %s ", prgname);
 	eal_common_usage();
 	printf("EAL Linux options:\n"
-	       "  --"OPT_SOCKET_MEM"        Memory to allocate on sockets (comma separated values)\n"
-	       "  --"OPT_SOCKET_LIMIT"      Limit memory allocation on sockets (comma separated values)\n"
+	       "  --"OPT_NUMA_MEM"        Memory to allocate on NUMA nodes (comma separated values)\n"
+	       "  --"OPT_NUMA_LIMIT"      Limit memory allocation on NUMA nodes (comma separated values)\n"
 	       "  --"OPT_HUGE_DIR"          Directory where hugetlbfs is mounted\n"
 	       "  --"OPT_FILE_PREFIX"       Prefix for hugepage filenames\n"
 	       "  --"OPT_CREATE_UIO_DEV"    Create /dev/uioX (usually done by hotplug)\n"

lib/eal/linux/eal.c +0 -0

 				eal_usage(prgname);
 				ret = -1;
 				goto out;

lib/eal/linux/eal.c +0 -0

 				eal_usage(prgname);
 				ret = -1;
 				goto out;

This patch introduces a new field in the lcore structure that stores the physical package ID of the core. This field is populated during EAL init. It is not exposed through any external API's for now.

Signed-off-by Anatoly Burakov <[email protected]>

---

lib/eal/linux/eal_lcore.c +16 -0

+/*
+ * Get CPU package ID for a logical core.
+ *
+ * This searches each nodeX directories in /sys for the symlink for the given
+ * lcore_id and returns the numa node where the lcore is found. If lcore is not
+ * found on any numa node, returns zero.
+ */
+unsigned
+eal_cpu_package_id(unsigned lcore_id)
+{
+	char path[PATH_MAX];
+	unsigned long id;
+
+	int len = snprintf(path, sizeof(path),
+			SYS_CPU_DIR "/%s", lcore_id, PACKAGE_ID_FILE);
+	if (len <= 0 || (unsigned)len >= sizeof(path))

From: Anatoly Burakov [mailto:[email protected]]
Sent: Friday, 6 September 2024 13.47
To: [email protected]
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-
[email protected]/

Quoted 48 lines

From: Anatoly Burakov [mailto:[email protected]]
Sent: Friday, 6 September 2024 13.47
To: [email protected]
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.

Quoted 5 lines

[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-
[email protected]/

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.

From: Burakov, Anatoly [mailto:[email protected]]
Sent: Friday, 6 September 2024 14.46

Quoted 8 lines · Morten Brørup

Quoted 8 lines

From: Anatoly Burakov [mailto:[email protected]]
Sent: Friday, 6 September 2024 13.47
To: [email protected]
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

Quoted 1 line

Quoted 1 line

ago, so it's been a while since we've actually switched over to using the

term

Quoted 3 lines

Quoted 3 lines

"socket" to mean "NUMA node".

This wasn't a problem before, as most systems had one NUMA node per

physical

Quoted 4 lines

Quoted 4 lines

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

Quoted 1 line

Quoted 1 line

most of our documentation still uses outdated terms, and our API is ripe

with

Quoted 1 line

Quoted 1 line

references to "sockets" when in actuality we mean "NUMA nodes". This could

be

Quoted 4 lines

Quoted 4 lines

a
source of confusion.

While completely renaming all of our API's would be a huge effort, will

take a

Quoted 5 lines

Quoted 5 lines

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

Quoted 2 lines

Quoted 2 lines

do
some tweaks around the edges and at least document this unfortunate

reality.

Quoted 4 lines

Quoted 4 lines

This patchset suggests the following changes:

- Update rte_socket/rte_lcore documentation to refer to NUMA nodes rather

than

Quoted 1 line

Quoted 1 line

sockets - Rename internal structures' fields to better reflect this

intention

Quoted 2 lines

Quoted 2 lines

-
Rename --socket-mem/--socket-limit flags to refer to NUMA rather than

sockets

Quoted 4 lines

Quoted 4 lines

-
Add internal API to get physical package ID [1]

The documentation is updated to refer to new EAL flags, but is otherwise

left

Quoted 3 lines

Quoted 3 lines

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

Quoted 11 lines

Quoted 10 lines

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-
[email protected]/

Quoted 3 lines

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().

Quoted 2 lines

For backwards compatibility, macros/functions with the old names can be

added.

Quoted 1 line

I don't think we can do such changes without deprecation notices, but it's a good candidate for next release.

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.

--
Thanks,
Anatoly

Quoted 75 lines

From: Burakov, Anatoly [mailto:[email protected]]
Sent: Friday, 6 September 2024 14.46

Quoted 8 lines · Morten Brørup

Quoted 8 lines

From: Anatoly Burakov [mailto:[email protected]]
Sent: Friday, 6 September 2024 13.47
To: [email protected]
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

Quoted 1 line

Quoted 1 line

ago, so it's been a while since we've actually switched over to using the

term

Quoted 3 lines

Quoted 3 lines

"socket" to mean "NUMA node".

This wasn't a problem before, as most systems had one NUMA node per

physical

Quoted 4 lines

Quoted 4 lines

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

Quoted 1 line

Quoted 1 line

most of our documentation still uses outdated terms, and our API is ripe

with

Quoted 1 line

Quoted 1 line

references to "sockets" when in actuality we mean "NUMA nodes". This could

be

Quoted 4 lines

Quoted 4 lines

a
source of confusion.

While completely renaming all of our API's would be a huge effort, will

take a

Quoted 5 lines

Quoted 5 lines

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

Quoted 2 lines

Quoted 2 lines

do
some tweaks around the edges and at least document this unfortunate

reality.

Quoted 4 lines

Quoted 4 lines

This patchset suggests the following changes:

- Update rte_socket/rte_lcore documentation to refer to NUMA nodes rather

than

Quoted 1 line

Quoted 1 line

sockets - Rename internal structures' fields to better reflect this

intention

Quoted 2 lines

Quoted 2 lines

-
Rename --socket-mem/--socket-limit flags to refer to NUMA rather than

sockets

Quoted 4 lines

Quoted 4 lines

-
Add internal API to get physical package ID [1]

The documentation is updated to refer to new EAL flags, but is otherwise

left

Quoted 3 lines

Quoted 3 lines

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

Quoted 11 lines

Quoted 10 lines

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-
[email protected]/

Quoted 3 lines

Thank you for cleaning this up, Anatoly.

I would prefer to take one more step and also rename functions and

Quoted 8 lines

parameters, e.g. rte_socket_id() -> rte_numa_id().

Quoted 2 lines

For backwards compatibility, macros/functions with the old names can be

added.

Quoted 1 line

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.

Quoted 4 lines

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.

Quoted 86 lines · Morten Brørup

Quoted 75 lines

From: Burakov, Anatoly [mailto:[email protected]]
Sent: Friday, 6 September 2024 14.46

Quoted 8 lines · Morten Brørup

Quoted 8 lines

From: Anatoly Burakov [mailto:[email protected]]
Sent: Friday, 6 September 2024 13.47
To: [email protected]
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

Quoted 1 line

Quoted 1 line

ago, so it's been a while since we've actually switched over to using the

term

Quoted 3 lines

Quoted 3 lines

"socket" to mean "NUMA node".

This wasn't a problem before, as most systems had one NUMA node per

physical

Quoted 4 lines

Quoted 4 lines

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

Quoted 1 line

Quoted 1 line

most of our documentation still uses outdated terms, and our API is ripe

with

Quoted 1 line

Quoted 1 line

references to "sockets" when in actuality we mean "NUMA nodes". This could

be

Quoted 4 lines

Quoted 4 lines

a
source of confusion.

While completely renaming all of our API's would be a huge effort, will

take a

Quoted 5 lines

Quoted 5 lines

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

Quoted 2 lines

Quoted 2 lines

do
some tweaks around the edges and at least document this unfortunate

reality.

Quoted 4 lines

Quoted 4 lines

This patchset suggests the following changes:

- Update rte_socket/rte_lcore documentation to refer to NUMA nodes rather

than

Quoted 1 line

Quoted 1 line

sockets - Rename internal structures' fields to better reflect this

intention

Quoted 2 lines

Quoted 2 lines

-
Rename --socket-mem/--socket-limit flags to refer to NUMA rather than

sockets

Quoted 4 lines

Quoted 4 lines

-
Add internal API to get physical package ID [1]

The documentation is updated to refer to new EAL flags, but is otherwise

left

Quoted 3 lines

Quoted 3 lines

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

Quoted 11 lines

Quoted 10 lines

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-
[email protected]/

Quoted 3 lines

Thank you for cleaning this up, Anatoly.

I would prefer to take one more step and also rename functions and

Quoted 8 lines

parameters, e.g. rte_socket_id() -> rte_numa_id().

Quoted 2 lines

For backwards compatibility, macros/functions with the old names can be

added.

Quoted 1 line

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.

Quoted 9 lines

The Devil is in the details, and I haven't looked deeply into this. So take with a grain of salt.

Quoted 4 lines

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.

From: Burakov, Anatoly [mailto:[email protected]]
Sent: Friday, 6 September 2024 15.18
Subject: Re: [RFC PATCH v1 0/5] Adjust wording for NUMA vs. socket ID in DPDK

Quoted 9 lines · Bruce Richardson

Quoted 8 lines · Morten Brørup

Quoted 8 lines

From: Burakov, Anatoly [mailto:[email protected]]
Sent: Friday, 6 September 2024 14.46

Quoted 4 lines · Morten Brørup

Quoted 4 lines

From: Anatoly Burakov [mailto:[email protected]]
Sent: Friday, 6 September 2024 13.47
To: [email protected]
Subject: [RFC PATCH v1 0/5] Adjust wording for NUMA vs. socket ID in

DPDK

Quoted 6 lines

Quoted 6 lines

Quoted 6 lines

Quoted 4 lines

Quoted 4 lines

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

Quoted 1 line

Quoted 1 line

ago, so it's been a while since we've actually switched over to using

the

Quoted 6 lines

Quoted 6 lines

Quoted 6 lines

term

Quoted 3 lines

Quoted 3 lines

"socket" to mean "NUMA node".

This wasn't a problem before, as most systems had one NUMA node per

physical

Quoted 1 line

Quoted 1 line

socket. However, in the last few years, more and more systems have

multiple

Quoted 7 lines

Quoted 7 lines

Quoted 7 lines

Quoted 3 lines

Quoted 3 lines

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

Quoted 1 line

Quoted 1 line

most of our documentation still uses outdated terms, and our API is ripe

with

Quoted 1 line

Quoted 1 line

references to "sockets" when in actuality we mean "NUMA nodes". This

could

Quoted 7 lines

Quoted 7 lines

Quoted 7 lines

be

Quoted 4 lines

Quoted 4 lines

a
source of confusion.

While completely renaming all of our API's would be a huge effort, will

take a

Quoted 1 line

Quoted 1 line

long time and arguably wouldn't even be worth the API breakages (given

that

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

this
mismatch between terminology and reality is implicitly understood by

most

Quoted 10 lines

Quoted 10 lines

Quoted 10 lines

Quoted 2 lines

Quoted 2 lines

people
working on DPDK, and so this isn't so much of a problem in practice), we

can

Quoted 2 lines

Quoted 2 lines

do
some tweaks around the edges and at least document this unfortunate

reality.

Quoted 4 lines

Quoted 4 lines

This patchset suggests the following changes:

- Update rte_socket/rte_lcore documentation to refer to NUMA nodes

rather

Quoted 5 lines

Quoted 5 lines

Quoted 5 lines

than

Quoted 1 line

Quoted 1 line

sockets - Rename internal structures' fields to better reflect this

intention

Quoted 2 lines

Quoted 2 lines

-
Rename --socket-mem/--socket-limit flags to refer to NUMA rather than

Quoted 7 lines

Quoted 7 lines

Quoted 7 lines

sockets

Quoted 4 lines

Quoted 4 lines

-
Add internal API to get physical package ID [1]

The documentation is updated to refer to new EAL flags, but is otherwise

left

Quoted 1 line

Quoted 1 line

untouched, and instead the entry in "glossary" is amended to indicate

that

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

when
DPDK documentation refers to "sockets", it actually means "NUMA ID's".

As

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

next

Quoted 1 line

Quoted 1 line

steps, we could rename all API parameters to refer to NUMA ID rather

than

Quoted 15 lines

Quoted 15 lines

Quoted 15 lines

Quoted 10 lines

Quoted 9 lines

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-
[email protected]/

Quoted 3 lines

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().

Quoted 1 line

Quoted 8 lines

Quoted 8 lines

Quoted 6 lines

Quoted 1 line

For backwards compatibility, macros/functions with the old names can be

added.

Quoted 1 line

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.

Quoted 2 lines

Quoted 2 lines

The Devil is in the details, and I haven't looked deeply into this. So take

with a grain of salt.

Quoted 7 lines

Quoted 7 lines

Quoted 5 lines

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.

Quoted 10 lines

Quoted 1 line

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.

Quoted 4 lines

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.

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/[email protected]/

Anatoly Burakov (5):
eal: update socket ID API documentation
lcore: rename socket ID to NUMA ID
eal: rename socket ID to NUMA ID in internal config
eal: rename --socket-mem/--socket-limit
lcore: store physical package ID internally

 doc/guides/faq/faq.rst                        |  4 +--
 doc/guides/howto/lm_bond_virtio_sriov.rst     |  2 +-
 doc/guides/howto/lm_virtio_vhost_user.rst     |  2 +-
 doc/guides/howto/pvp_reference_benchmark.rst  |  4 +--
 .../virtio_user_for_container_networking.rst  |  2 +-
 doc/guides/linux_gsg/build_sample_apps.rst    | 20 +++++------
 doc/guides/linux_gsg/linux_eal_parameters.rst | 16 ++++-----
 doc/guides/nics/mlx4.rst                      |  2 +-
 doc/guides/nics/mlx5.rst                      |  2 +-
 .../prog_guide/env_abstraction_layer.rst      | 12 +++----
 doc/guides/prog_guide/glossary.rst            |  5 ++-
 doc/guides/prog_guide/multi_proc_support.rst  |  2 +-
 doc/guides/sample_app_ug/bbdev_app.rst        |  6 ++--
 doc/guides/sample_app_ug/ipsec_secgw.rst      |  6 ++--
 doc/guides/sample_app_ug/vdpa.rst             |  2 +-
 doc/guides/sample_app_ug/vhost.rst            |  4 +--
 lib/eal/common/eal_common_dynmem.c            | 14 ++++----
 lib/eal/common/eal_common_lcore.c             | 28 +++++++++++++---
 lib/eal/common/eal_common_options.c           | 33 ++++++++++---------
 lib/eal/common/eal_common_thread.c            | 12 +++----
 lib/eal/common/eal_internal_cfg.h             | 10 +++---
 lib/eal/common/eal_options.h                  |  8 +++--
 lib/eal/common/eal_private.h                  |  5 ++-
 lib/eal/common/eal_thread.h                   | 11 +++++++
 lib/eal/common/malloc_heap.c                  |  2 +-
 lib/eal/freebsd/eal.c                         |  2 +-
 lib/eal/freebsd/eal_lcore.c                   |  6 ++++
 lib/eal/include/rte_lcore.h                   | 25 +++++++-------
 lib/eal/linux/eal.c                           | 22 ++++++-------
 lib/eal/linux/eal_lcore.c                     | 28 ++++++++++++++++
 lib/eal/linux/eal_memory.c                    | 22 ++++++-------
 lib/eal/windows/eal.c                         |  2 +-
 lib/eal/windows/eal_lcore.c                   |  7 ++++
 33 files changed, 204 insertions(+), 124 deletions(-)