DPDK patches and discussions
 help / color / mirror / Atom feed
From: Anatoly Burakov <anatoly.burakov@intel.com>
To: dev@dpdk.org, Matan Azrad <matan@nvidia.com>,
	Viacheslav Ovsiienko <viacheslavo@nvidia.com>,
	Dariusz Sosnowski <dsosnowski@nvidia.com>,
	Bing Zhao <bingz@nvidia.com>, Ori Kam <orika@nvidia.com>,
	Suanming Mou <suanmingm@nvidia.com>,
	Tyler Retzlaff <roretzla@linux.microsoft.com>,
	Nicolas Chautru <nicolas.chautru@intel.com>,
	Radu Nicolau <radu.nicolau@intel.com>,
	Akhil Goyal <gakhil@marvell.com>,
	Maxime Coquelin <maxime.coquelin@redhat.com>,
	Chenbo Xia <chenbox@nvidia.com>
Subject: [PATCH v1 4/4] eal: rename --socket-mem/--socket-limit
Date: Tue, 26 Nov 2024 13:14:50 +0000	[thread overview]
Message-ID: <e5fe38daf2116b7254f739b8b97598683b4e4d20.1732626792.git.anatoly.burakov@intel.com> (raw)
In-Reply-To: <cover.1732626792.git.anatoly.burakov@intel.com>

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 <anatoly.burakov@intel.com>
---

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.

 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/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_options.c           | 17 +++++++++-------
 lib/eal/common/eal_options.h                  |  8 +++++---
 lib/eal/linux/eal.c                           | 18 +++++++++++------
 18 files changed, 70 insertions(+), 59 deletions(-)

diff --git a/doc/guides/faq/faq.rst b/doc/guides/faq/faq.rst
index 2aec432d75..8557d9daf9 100644
--- a/doc/guides/faq/faq.rst
+++ b/doc/guides/faq/faq.rst
@@ -31,7 +31,7 @@ If I execute "l2fwd -l 0-3 -m 64 -n 3 -- -p 3", I get the following output, indi
 I have set up a total of 1024 Hugepages (that is, allocated 512 2M pages to each NUMA node).
 
 The -m command line parameter does not guarantee that huge pages will be reserved on specific sockets. Therefore, allocated huge pages may not be on socket 0.
-To request memory to be reserved on a specific socket, please use the --socket-mem command-line parameter instead of -m.
+To request memory to be reserved on a specific socket, please use the --numa-mem command-line parameter instead of -m.
 
 
 I am running a 32-bit DPDK application on a NUMA system, and sometimes the application initializes fine but cannot allocate memory. Why is that happening?
@@ -54,7 +54,7 @@ For example, if your EAL coremask is 0xff0, the main core will usually be the fi
 .. Note: Instead of '-c 0xff0' use the '-l 4-11' as a cleaner way to define lcores.
 
 In this way, the hugepages have a greater chance of being allocated to the correct socket.
-Additionally, a ``--socket-mem`` option could be used to ensure the availability of memory for each socket, so that if hugepages were allocated on
+Additionally, a ``--numa-mem`` option could be used to ensure the availability of memory for each socket, so that if hugepages were allocated on
 the wrong socket, the application simply will not start.
 
 
diff --git a/doc/guides/howto/lm_bond_virtio_sriov.rst b/doc/guides/howto/lm_bond_virtio_sriov.rst
index 60b4462c2c..1859508559 100644
--- a/doc/guides/howto/lm_bond_virtio_sriov.rst
+++ b/doc/guides/howto/lm_bond_virtio_sriov.rst
@@ -614,7 +614,7 @@ Run testpmd in the Virtual Machine.
    # use for bonding of virtio and vf tests in VM
 
    /root/dpdk/<build_dir>/app/dpdk-testpmd \
-   -l 0-3 -n 4 --socket-mem 350 --  --i --port-topology=chained
+   -l 0-3 -n 4 --numa-mem 350 --  --i --port-topology=chained
 
 .. _lm_bond_virtio_sriov_switch_conf:
 
diff --git a/doc/guides/howto/lm_virtio_vhost_user.rst b/doc/guides/howto/lm_virtio_vhost_user.rst
index c5c48f10a9..b84ef0dc29 100644
--- a/doc/guides/howto/lm_virtio_vhost_user.rst
+++ b/doc/guides/howto/lm_virtio_vhost_user.rst
@@ -438,4 +438,4 @@ run_testpmd_in_vm.sh
    # test system has 8 cpus (0-7), use cpus 2-7 for VM
 
    /root/dpdk/<build_dir>/app/dpdk-testpmd \
-   -l 0-5 -n 4 --socket-mem 350 -- --burst=64 --i
+   -l 0-5 -n 4 --numa-mem 350 -- --burst=64 --i
diff --git a/doc/guides/howto/pvp_reference_benchmark.rst b/doc/guides/howto/pvp_reference_benchmark.rst
index 1043356b3d..073e72ea6f 100644
--- a/doc/guides/howto/pvp_reference_benchmark.rst
+++ b/doc/guides/howto/pvp_reference_benchmark.rst
@@ -122,7 +122,7 @@ Testpmd launch
 
    .. code-block:: console
 
-      <build_dir>/app/dpdk-testpmd -l 0,2,3,4,5 --socket-mem=1024 -n 4 \
+      <build_dir>/app/dpdk-testpmd -l 0,2,3,4,5 --numa-mem=1024 -n 4 \
           --vdev 'net_vhost0,iface=/tmp/vhost-user1' \
           --vdev 'net_vhost1,iface=/tmp/vhost-user2' -- \
           --portmask=f -i --rxq=1 --txq=1 \
@@ -332,7 +332,7 @@ Start testpmd:
 
    .. code-block:: console
 
-      <build_dir>/app/dpdk-testpmd -l 0,1,2 --socket-mem 1024 -n 4 \
+      <build_dir>/app/dpdk-testpmd -l 0,1,2 --numa-mem 1024 -n 4 \
           --proc-type auto --file-prefix pg -- \
           --portmask=3 --forward-mode=macswap --port-topology=chained \
           --disable-rss -i --rxq=1 --txq=1 \
diff --git a/doc/guides/howto/virtio_user_for_container_networking.rst b/doc/guides/howto/virtio_user_for_container_networking.rst
index 5eab360a1c..a07dfd45b0 100644
--- a/doc/guides/howto/virtio_user_for_container_networking.rst
+++ b/doc/guides/howto/virtio_user_for_container_networking.rst
@@ -77,7 +77,7 @@ some minor changes.
 
     .. code-block:: console
 
-        $(testpmd) -l 0-1 -n 4 --socket-mem 1024,1024 \
+        $(testpmd) -l 0-1 -n 4 --numa-mem 1024,1024 \
             --vdev 'eth_vhost0,iface=/tmp/sock0' \
             --file-prefix=host --no-pci -- -i
 
diff --git a/doc/guides/linux_gsg/build_sample_apps.rst b/doc/guides/linux_gsg/build_sample_apps.rst
index 433839ecc7..5746a623f8 100644
--- a/doc/guides/linux_gsg/build_sample_apps.rst
+++ b/doc/guides/linux_gsg/build_sample_apps.rst
@@ -34,7 +34,7 @@ The following is the list of options that can be given to the EAL:
 .. code-block:: console
 
     ./rte-app [-c COREMASK | -l CORELIST] [-n NUM] [-b <domain:bus:devid.func>] \
-              [--socket-mem=MB,...] [-d LIB.so|DIR] [-m MB] [-r NUM] [-v] [--file-prefix] \
+              [--numa-mem=MB,...] [-d LIB.so|DIR] [-m MB] [-r NUM] [-v] [--file-prefix] \
 	      [--proc-type <primary|secondary|auto>]
 
 The EAL options are as follows:
@@ -55,12 +55,12 @@ The EAL options are as follows:
   use the specified Ethernet device(s) only. Use comma-separate
   ``[domain:]bus:devid.func`` values. Cannot be used with ``-b`` option.
 
-* ``--socket-mem``:
+* ``--numa-mem``:
   Memory to allocate from hugepages on specific sockets. In dynamic memory mode,
   this memory will also be pinned (i.e. not released back to the system until
   application closes).
 
-* ``--socket-limit``:
+* ``--numa-limit``:
   Limit maximum memory available for allocation on each socket. Does not support
   legacy memory mode.
 
@@ -71,7 +71,7 @@ The EAL options are as follows:
 
 * ``-m MB``:
   Memory to allocate from hugepages, regardless of processor socket. It is
-  recommended that ``--socket-mem`` be used instead of this option.
+  recommended that ``--numa-mem`` be used instead of this option.
 
 * ``-r NUM``:
   Number of memory ranks.
@@ -158,9 +158,9 @@ Hugepage Memory Use by Applications
 
 When running an application, it is recommended to use the same amount of memory as that allocated for hugepages.
 This is done automatically by the DPDK application at startup,
-if no ``-m`` or ``--socket-mem`` parameter is passed to it when run.
+if no ``-m`` or ``--numa-mem`` parameter is passed to it when run.
 
-If more memory is requested by explicitly passing a ``-m`` or ``--socket-mem`` value, the application fails.
+If more memory is requested by explicitly passing a ``-m`` or ``--numa-mem`` value, the application fails.
 However, the application itself can also fail if the user requests less memory than the reserved amount of hugepage-memory, particularly if using the ``-m`` option.
 The reason is as follows.
 Suppose the system has 1024 reserved 2 MB pages in socket 0 and 1024 in socket 1.
@@ -168,15 +168,15 @@ If the user requests 128 MB of memory, the 64 pages may not match the constraint
 
 *   The hugepage memory by be given to the application by the kernel in socket 1 only.
     In this case, if the application attempts to create an object, such as a ring or memory pool in socket 0, it fails.
-    To avoid this issue, it is recommended that the ``--socket-mem`` option be used instead of the ``-m`` option.
+    To avoid this issue, it is recommended that the ``--numa-mem`` option be used instead of the ``-m`` option.
 
 *   These pages can be located anywhere in physical memory, and, although the DPDK EAL will attempt to allocate memory in contiguous blocks,
     it is possible that the pages will not be contiguous. In this case, the application is not able to allocate big memory pools.
 
 The socket-mem option can be used to request specific amounts of memory for specific sockets.
-This is accomplished by supplying the ``--socket-mem`` flag followed by amounts of memory requested on each socket,
-for example, supply ``--socket-mem=0,512`` to try and reserve 512 MB for socket 1 only.
-Similarly, on a four socket system, to allocate 1 GB memory on each of sockets 0 and 2 only, the parameter ``--socket-mem=1024,0,1024`` can be used.
+This is accomplished by supplying the ``--numa-mem`` flag followed by amounts of memory requested on each socket,
+for example, supply ``--numa-mem=0,512`` to try and reserve 512 MB for socket 1 only.
+Similarly, on a four socket system, to allocate 1 GB memory on each of sockets 0 and 2 only, the parameter ``--numa-mem=1024,0,1024`` can be used.
 No memory will be reserved on any CPU socket that is not explicitly referenced, for example, socket 3 in this case.
 If the DPDK cannot allocate enough memory on each socket, the EAL initialization fails.
 
diff --git a/doc/guides/linux_gsg/linux_eal_parameters.rst b/doc/guides/linux_gsg/linux_eal_parameters.rst
index ea8f381391..7c5b26ce26 100644
--- a/doc/guides/linux_gsg/linux_eal_parameters.rst
+++ b/doc/guides/linux_gsg/linux_eal_parameters.rst
@@ -60,20 +60,20 @@ Memory-related options
 
     Use legacy DPDK memory allocation mode.
 
-*   ``--socket-mem <amounts of memory per socket>``
+*   ``--numa-mem <amounts of memory per NUMA node>``
 
-    Preallocate specified amounts of memory per socket. The parameter is a
+    Preallocate specified amounts of memory per NUMA node. The parameter is a
     comma-separated list of values. For example::
 
-        --socket-mem 1024,2048
+        --numa-mem 1024,2048
 
-    This will allocate 1 gigabyte of memory on socket 0, and 2048 megabytes of
-    memory on socket 1.
+    This will allocate 1 gigabyte of memory on NUMA node 0, and 2048 megabytes of
+    memory on NUMA node 1.
 
-*   ``--socket-limit <amounts of memory per socket>``
+*   ``--numa-limit <amounts of memory per NUMA node>``
 
-    Place a per-socket upper limit on memory use (non-legacy memory mode only).
-    0 will disable the limit for a particular socket.
+    Place a per-NUMA node upper limit on memory use (non-legacy memory mode only).
+    0 will disable the limit for a particular NUMA node.
 
 *   ``--single-file-segments``
 
diff --git a/doc/guides/nics/mlx4.rst b/doc/guides/nics/mlx4.rst
index ecc5a32913..d79d5b1661 100644
--- a/doc/guides/nics/mlx4.rst
+++ b/doc/guides/nics/mlx4.rst
@@ -364,7 +364,7 @@ Performance tuning
 
 #. To minimize overhead of searching Memory Regions:
 
-   - '--socket-mem' is recommended to pin memory by predictable amount.
+   - '--numa-mem' is recommended to pin memory by predictable amount.
    - Configure per-lcore cache when creating Mempools for packet buffer.
    - Refrain from dynamically allocating/freeing memory in run-time.
 
diff --git a/doc/guides/nics/mlx5.rst b/doc/guides/nics/mlx5.rst
index 38226d5213..5276492c7d 100644
--- a/doc/guides/nics/mlx5.rst
+++ b/doc/guides/nics/mlx5.rst
@@ -1776,7 +1776,7 @@ Performance tuning
 
 #. To minimize overhead of searching Memory Regions:
 
-   - '--socket-mem' is recommended to pin memory by predictable amount.
+   - '--numa-mem' is recommended to pin memory by predictable amount.
    - Configure per-lcore cache when creating Mempools for packet buffer.
    - Refrain from dynamically allocating/freeing memory in run-time.
 
diff --git a/doc/guides/prog_guide/env_abstraction_layer.rst b/doc/guides/prog_guide/env_abstraction_layer.rst
index 04214a05b2..099ea397c3 100644
--- a/doc/guides/prog_guide/env_abstraction_layer.rst
+++ b/doc/guides/prog_guide/env_abstraction_layer.rst
@@ -119,11 +119,11 @@ in use, either reserved memory will satisfy the requirements, or the allocation
 will fail.
 
 There is no need to preallocate any memory at startup using ``-m`` or
-``--socket-mem`` command-line parameters, however it is still possible to do so,
+``--numa-mem`` command-line parameters, however it is still possible to do so,
 in which case preallocate memory will be "pinned" (i.e. will never be released
 by the application back to the system). It will be possible to allocate more
 hugepages, and deallocate those, but any preallocated pages will not be freed.
-If neither ``-m`` nor ``--socket-mem`` were specified, no memory will be
+If neither ``-m`` nor ``--numa-mem`` were specified, no memory will be
 preallocated, and all memory will be allocated at runtime, as needed.
 
 Another available option to use in dynamic memory mode is
@@ -143,7 +143,7 @@ to deny them), allocation validator callbacks are also available via
 ``rte_mem_alloc_validator_callback_register()`` function.
 
 A default validator callback is provided by EAL, which can be enabled with a
-``--socket-limit`` command-line option, for a simple way to limit maximum amount
+``--numa-limit`` command-line option, for a simple way to limit maximum amount
 of memory that can be used by DPDK application.
 
 .. warning::
@@ -164,7 +164,7 @@ This mode mimics historical behavior of EAL. That is, EAL will reserve all
 memory at startup, sort all memory into large IOVA-contiguous chunks, and will
 not allow acquiring or releasing hugepages from the system at runtime.
 
-If neither ``-m`` nor ``--socket-mem`` were specified, the entire available
+If neither ``-m`` nor ``--numa-mem`` were specified, the entire available
 hugepage memory will be preallocated.
 
 Hugepage Allocation Matching
@@ -187,7 +187,7 @@ very dependent on the memory allocation patterns of the application.
 
 Additional restrictions are present when running in 32-bit mode. In dynamic
 memory mode, by default maximum of 2 gigabytes of VA space will be preallocated,
-and all of it will be on main lcore NUMA node unless ``--socket-mem`` flag is
+and all of it will be on main lcore NUMA node unless ``--numa-mem`` flag is
 used.
 
 In legacy mode, VA space will only be preallocated for segments that were
@@ -1216,7 +1216,7 @@ into a single block.
 If deallocating pages at runtime is supported, and the free element encloses
 one or more pages, those pages can be deallocated and be removed from the heap.
 If DPDK was started with command-line parameters for preallocating memory
-(``-m`` or ``--socket-mem``), then those pages that were allocated at startup
+(``-m`` or ``--numa-mem``), then those pages that were allocated at startup
 will not be deallocated.
 
 Any successful deallocation event will trigger a callback, for which user
diff --git a/doc/guides/prog_guide/multi_proc_support.rst b/doc/guides/prog_guide/multi_proc_support.rst
index 0c57145470..3082ffe183 100644
--- a/doc/guides/prog_guide/multi_proc_support.rst
+++ b/doc/guides/prog_guide/multi_proc_support.rst
@@ -127,7 +127,7 @@ allocate more memory than they need. However if ``--legacy-mem`` is used, DPDK
 will attempt to preallocate all memory it can get to, and memory use must be
 explicitly limited. This is done by passing the ``-m`` flag to each process to
 specify how much hugepage memory, in megabytes, each process can use (or passing
-``--socket-mem`` to specify how much hugepage memory on each socket each process
+``--numa-mem`` to specify how much hugepage memory on each socket each process
 can use).
 
 .. note::
diff --git a/doc/guides/sample_app_ug/bbdev_app.rst b/doc/guides/sample_app_ug/bbdev_app.rst
index 7f02f0ed90..bd1387cb5c 100644
--- a/doc/guides/sample_app_ug/bbdev_app.rst
+++ b/doc/guides/sample_app_ug/bbdev_app.rst
@@ -67,7 +67,7 @@ issue the command:
 .. code-block:: console
 
     $ ./<build_dir>/examples/dpdk-bbdev --vdev='baseband_turbo_sw' -a <NIC0PCIADDR> \
-    -c 0x38 --socket-mem=2,2 --file-prefix=bbdev -- -e 0x10 -d 0x20
+    -c 0x38 --numa-mem=2,2 --file-prefix=bbdev -- -e 0x10 -d 0x20
 
 where, NIC0PCIADDR is the PCI address of the Rx port
 
@@ -99,12 +99,12 @@ ports.
 .. code-block:: console
 
     $ ./pktgen-3.4.0/app/x86_64-native-linux-gcc/pktgen -c 0x3 \
-    --socket-mem=1,1 --file-prefix=pg -a <NIC1PCIADDR> -- -m 1.0 -P
+    --numa-mem=1,1 --file-prefix=pg -a <NIC1PCIADDR> -- -m 1.0 -P
 
 where:
 
 * ``-c COREMASK``: A hexadecimal bitmask of cores to run on
-* ``--socket-mem``: Memory to allocate on specific sockets (use comma separated values)
+* ``--numa-mem``: Memory to allocate on specific sockets (use comma separated values)
 * ``--file-prefix``: Prefix for hugepage filenames
 * ``-a <NIC1PCIADDR>``: Add a PCI device in allow list. The argument format is <[domain:]bus:devid.func>.
 * ``-m <string>``: Matrix for mapping ports to logical cores.
diff --git a/doc/guides/sample_app_ug/ipsec_secgw.rst b/doc/guides/sample_app_ug/ipsec_secgw.rst
index cada8c375f..7dce577de9 100644
--- a/doc/guides/sample_app_ug/ipsec_secgw.rst
+++ b/doc/guides/sample_app_ug/ipsec_secgw.rst
@@ -270,7 +270,7 @@ The mapping of lcores to port/queues is similar to other l3fwd applications.
 
 For example, given the following command line to run application in poll mode::
 
-    ./<build_dir>/examples/dpdk-ipsec-secgw -l 20,21 -n 4 --socket-mem 0,2048       \
+    ./<build_dir>/examples/dpdk-ipsec-secgw -l 20,21 -n 4 --numa-mem 0,2048       \
            --vdev "crypto_null" -- -p 0xf -P -u 0x3             \
            --config="(0,0,20),(1,0,20),(2,0,21),(3,0,21)"       \
            -f /path/to/config_file --transfer-mode poll         \
@@ -281,7 +281,7 @@ where each option means:
 
 *   The ``-n`` option sets memory 4 channels.
 
-*   The ``--socket-mem`` to use 2GB on socket 1.
+*   The ``--numa-mem`` to use 2GB on socket 1.
 
 *   The ``--vdev "crypto_null"`` option creates virtual NULL cryptodev PMD.
 
@@ -368,7 +368,7 @@ For example, something like the following command line:
 
 .. code-block:: console
 
-    ./<build_dir>/examples/dpdk-ipsec-secgw -l 20,21 -n 4 --socket-mem 0,2048 \
+    ./<build_dir>/examples/dpdk-ipsec-secgw -l 20,21 -n 4 --numa-mem 0,2048 \
             -a 81:00.0 -a 81:00.1 -a 81:00.2 -a 81:00.3 \
             --vdev "crypto_aesni_mb" --vdev "crypto_null" \
 	    -- \
diff --git a/doc/guides/sample_app_ug/vdpa.rst b/doc/guides/sample_app_ug/vdpa.rst
index bc11242d03..f3e96f36d7 100644
--- a/doc/guides/sample_app_ug/vdpa.rst
+++ b/doc/guides/sample_app_ug/vdpa.rst
@@ -54,7 +54,7 @@ Take IFCVF driver for example:
 
 .. code-block:: console
 
-        ./dpdk-vdpa -c 0x2 -n 4 --socket-mem 1024,1024 \
+        ./dpdk-vdpa -c 0x2 -n 4 --numa-mem 1024,1024 \
                 -a 0000:06:00.3,vdpa=1 -a 0000:06:00.4,vdpa=1 \
                 -- --interactive
 
diff --git a/doc/guides/sample_app_ug/vhost.rst b/doc/guides/sample_app_ug/vhost.rst
index 982e19214d..ec2805a0c9 100644
--- a/doc/guides/sample_app_ug/vhost.rst
+++ b/doc/guides/sample_app_ug/vhost.rst
@@ -60,7 +60,7 @@ Start the vswitch example
 
 .. code-block:: console
 
-        ./dpdk-vhost -l 0-3 -n 4 --socket-mem 1024  \
+        ./dpdk-vhost -l 0-3 -n 4 --numa-mem 1024  \
              -- --socket-file /tmp/sock0 --client \
              ...
 
@@ -218,5 +218,5 @@ Common Issues
   pre-allocation
 
   The builtin example doesn't support dynamic memory allocation. When vhost
-  backend enables "builtin-net-driver", "--socket-mem" option should be
+  backend enables "builtin-net-driver", "--numa-mem" option should be
   added at virtio-user PMD side as a startup item.
diff --git a/lib/eal/common/eal_common_options.c b/lib/eal/common/eal_common_options.c
index ab95674c2e..378d7f51ca 100644
--- a/lib/eal/common/eal_common_options.c
+++ b/lib/eal/common/eal_common_options.c
@@ -90,8 +90,11 @@ eal_long_options[] = {
 	{OPT_DEV_BLOCK,         1, NULL, OPT_DEV_BLOCK_NUM        },
 	{OPT_DEV_ALLOW,		1, NULL, OPT_DEV_ALLOW_NUM	  },
 	{OPT_PROC_TYPE,         1, NULL, OPT_PROC_TYPE_NUM        },
-	{OPT_SOCKET_MEM,        1, NULL, OPT_SOCKET_MEM_NUM       },
-	{OPT_SOCKET_LIMIT,      1, NULL, OPT_SOCKET_LIMIT_NUM     },
+	/* socket-mem/socket-limit are kept for backwards compatiblity */
+	{OPT_SOCKET_MEM,        1, NULL, OPT_NUMA_MEM_NUM         },
+	{OPT_SOCKET_LIMIT,      1, NULL, OPT_NUMA_LIMIT_NUM       },
+	{OPT_NUMA_MEM,          1, NULL, OPT_NUMA_MEM_NUM         },
+	{OPT_NUMA_LIMIT,        1, NULL, OPT_NUMA_LIMIT_NUM       },
 #ifndef RTE_EXEC_ENV_WINDOWS
 	{OPT_SYSLOG,            2, NULL, OPT_SYSLOG_NUM           },
 #endif
@@ -2107,12 +2110,12 @@ eal_check_common_options(struct internal_config *internal_cfg)
 		return -1;
 	}
 	if (mem_parsed && internal_cfg->force_numa == 1) {
-		EAL_LOG(ERR, "Options -m and --"OPT_SOCKET_MEM" cannot "
+		EAL_LOG(ERR, "Options -m and --"OPT_NUMA_MEM" cannot "
 			"be specified at the same time");
 		return -1;
 	}
 	if (internal_cfg->no_hugetlbfs && internal_cfg->force_numa == 1) {
-		EAL_LOG(ERR, "Option --"OPT_SOCKET_MEM" cannot "
+		EAL_LOG(ERR, "Option --"OPT_NUMA_MEM" cannot "
 			"be specified together with --"OPT_NO_HUGE);
 		return -1;
 	}
@@ -2130,7 +2133,7 @@ eal_check_common_options(struct internal_config *internal_cfg)
 		return -1;
 	}
 	if (internal_conf->force_numa_limits && internal_conf->legacy_mem) {
-		EAL_LOG(ERR, "Option --"OPT_SOCKET_LIMIT
+		EAL_LOG(ERR, "Option --"OPT_NUMA_LIMIT
 			" is only supported in non-legacy memory mode");
 	}
 	if (internal_cfg->single_file_segments &&
@@ -2165,7 +2168,7 @@ eal_check_common_options(struct internal_config *internal_cfg)
 	if (internal_cfg->legacy_mem && internal_cfg->memory == 0) {
 		EAL_LOG(NOTICE, "Static memory layout is selected, "
 			"amount of reserved memory can be adjusted with "
-			"-m or --"OPT_SOCKET_MEM);
+			"-m or --"OPT_NUMA_MEM);
 	}
 
 	return 0;
@@ -2218,7 +2221,7 @@ eal_common_usage(void)
 	       "  --"OPT_MAIN_LCORE" ID     Core ID that is used as main\n"
 	       "  --"OPT_MBUF_POOL_OPS_NAME" Pool ops name for mbuf to use\n"
 	       "  -n CHANNELS         Number of memory channels\n"
-	       "  -m MB               Memory to allocate (see also --"OPT_SOCKET_MEM")\n"
+	       "  -m MB               Memory to allocate (see also --"OPT_NUMA_MEM")\n"
 	       "  -r RANKS            Force number of memory ranks (don't detect)\n"
 	       "  -b, --block         Add a device to the blocked list.\n"
 	       "                      Prevent EAL from using this device. The argument\n"
diff --git a/lib/eal/common/eal_options.h b/lib/eal/common/eal_options.h
index 95fb4f6108..1646dff44d 100644
--- a/lib/eal/common/eal_options.h
+++ b/lib/eal/common/eal_options.h
@@ -64,9 +64,11 @@ enum {
 #define OPT_IN_MEMORY         "in-memory"
 	OPT_IN_MEMORY_NUM,
 #define OPT_SOCKET_MEM        "socket-mem"
-	OPT_SOCKET_MEM_NUM,
-#define OPT_SOCKET_LIMIT        "socket-limit"
-	OPT_SOCKET_LIMIT_NUM,
+#define OPT_NUMA_MEM          "numa-mem"
+	OPT_NUMA_MEM_NUM,
+#define OPT_SOCKET_LIMIT      "socket-limit"
+#define OPT_NUMA_LIMIT        "numa-limit"
+	OPT_NUMA_LIMIT_NUM,
 #define OPT_SYSLOG            "syslog"
 	OPT_SYSLOG_NUM,
 #define OPT_VDEV              "vdev"
diff --git a/lib/eal/linux/eal.c b/lib/eal/linux/eal.c
index 4b8f855c00..ba1bfa9416 100644
--- a/lib/eal/linux/eal.c
+++ b/lib/eal/linux/eal.c
@@ -444,8 +444,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"
@@ -655,11 +655,14 @@ eal_parse_args(int argc, char **argv)
 			}
 			break;
 		}
-		case OPT_SOCKET_MEM_NUM:
+		case OPT_NUMA_MEM_NUM:
 			if (eal_parse_socket_arg(optarg,
 					internal_conf->numa_mem) < 0) {
 				EAL_LOG(ERR, "invalid parameters for --"
-						OPT_SOCKET_MEM);
+						OPT_NUMA_MEM
+						" (aka --"
+						OPT_SOCKET_MEM
+						")");
 				eal_usage(prgname);
 				ret = -1;
 				goto out;
@@ -667,11 +670,14 @@ eal_parse_args(int argc, char **argv)
 			internal_conf->force_numa = 1;
 			break;
 
-		case OPT_SOCKET_LIMIT_NUM:
+		case OPT_NUMA_LIMIT_NUM:
 			if (eal_parse_socket_arg(optarg,
 					internal_conf->numa_limit) < 0) {
 				EAL_LOG(ERR, "invalid parameters for --"
-						OPT_SOCKET_LIMIT);
+						OPT_NUMA_LIMIT
+						" (aka --"
+						OPT_SOCKET_LIMIT
+						")");
 				eal_usage(prgname);
 				ret = -1;
 				goto out;
-- 
2.43.5


      parent reply	other threads:[~2024-11-26 13:15 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-11-26 13:14 [PATCH v1 0/4] Adjust wording for NUMA vs. socket ID in DPDK Anatoly Burakov
2024-11-26 13:14 ` [PATCH v1 1/4] eal: update socket ID API documentation Anatoly Burakov
2024-11-26 13:14 ` [PATCH v1 2/4] lcore: rename socket ID to NUMA ID Anatoly Burakov
2024-11-26 13:14 ` [PATCH v1 3/4] eal: rename socket ID to NUMA ID in internal config Anatoly Burakov
2024-11-26 13:14 ` Anatoly Burakov [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=e5fe38daf2116b7254f739b8b97598683b4e4d20.1732626792.git.anatoly.burakov@intel.com \
    --to=anatoly.burakov@intel.com \
    --cc=bingz@nvidia.com \
    --cc=chenbox@nvidia.com \
    --cc=dev@dpdk.org \
    --cc=dsosnowski@nvidia.com \
    --cc=gakhil@marvell.com \
    --cc=matan@nvidia.com \
    --cc=maxime.coquelin@redhat.com \
    --cc=nicolas.chautru@intel.com \
    --cc=orika@nvidia.com \
    --cc=radu.nicolau@intel.com \
    --cc=roretzla@linux.microsoft.com \
    --cc=suanmingm@nvidia.com \
    --cc=viacheslavo@nvidia.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).