For long literal lines that exceed that limit try to wrap the text at sensible locations.
For example a long command line could be documented like this and still work if copied directly from the docs::
- build/app/testpmd -c7 -n3 --vdev=net_pcap0,iface=eth0 \
+ build/app/testpmd -l 0-2 -n3 --vdev=net_pcap0,iface=eth0 \
--vdev=net_pcap1,iface=eth1 \
-- -i --nb-cores=2 --nb-ports=2 \
--total-num-mbufs=2048
.. code-block:: console
- ./l2fwd-crypto -c 40 -n 4 --vdev="crypto_aesni_gcm,socket_id=1,max_nb_sessions=128"
+ ./l2fwd-crypto -l 6 -n 4 --vdev="crypto_aesni_gcm,socket_id=1,max_nb_sessions=128"
Limitations
-----------
.. code-block:: console
- ./l2fwd-crypto -c 40 -n 4 --vdev="crypto_aesni_mb,socket_id=1,max_nb_sessions=128"
+ ./l2fwd-crypto -l 6 -n 4 --vdev="crypto_aesni_mb,socket_id=1,max_nb_sessions=128"
.. code-block:: console
- ./l2fwd-crypto -c 40 -n 4 --vdev="crypto_kasumi,socket_id=1,max_nb_sessions=128"
+ ./l2fwd-crypto -l 6 -n 4 --vdev="crypto_kasumi,socket_id=1,max_nb_sessions=128"
.. code-block:: console
- ./l2fwd-crypto -c 40 -n 4 --vdev="crypto_null,socket_id=1,max_nb_sessions=128"
+ ./l2fwd-crypto -l 6 -n 4 --vdev="crypto_null,socket_id=1,max_nb_sessions=128"
.. code-block:: console
- sudo ./build/l2fwd-crypto -c 0x3 -n 4 --vdev "crypto_openssl"
+ sudo ./build/l2fwd-crypto -l 0-1 -n 4 --vdev "crypto_openssl"
--vdev "crypto_openssl"-- -p 0x3 --chain CIPHER_HASH
--cipher_op ENCRYPT --cipher_algo AES_CBC
--cipher_key 00:01:02:03:04:05:06:07:08:09:0a:0b:0c:0d:0e:0f
.. code-block:: console
- ./l2fwd-crypto -c 40 -n 4 --vdev="crypto_snow3g,socket_id=1,max_nb_sessions=128"
+ ./l2fwd-crypto -l 6 -n 4 --vdev="crypto_snow3g,socket_id=1,max_nb_sessions=128"
.. code-block:: console
- ./l2fwd-crypto -c 40 -n 4 --vdev="crypto_zuc,socket_id=1,max_nb_sessions=128"
+ ./l2fwd-crypto -l 6 -n 4 --vdev="crypto_zuc,socket_id=1,max_nb_sessions=128"
See the "Quick Start Setup Script" section in the :ref:`DPDK Getting Started Guide <linux_gsg>` for more information.
-If I execute "l2fwd -c f -m 64 -n 3 -- -p 3", I get the following output, indicating that there are no socket 0 hugepages to allocate the mbuf and ring structures to?
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------
+If I execute "l2fwd -l 0-3 -m 64 -n 3 -- -p 3", I get the following output, indicating that there are no socket 0 hugepages to allocate the mbuf and ring structures to?
+------------------------------------------------------------------------------------------------------------------------------------------------------------------------
I have set up a total of 1024 Hugepages (that is, allocated 512 2M pages to each NUMA node).
For example, if your EAL coremask is 0xff0, the master core will usually be the first core in the coremask (0x10); this is what you have to supply to taskset::
- taskset 0x10 ./l2fwd -c 0xff0 -n 2
+ taskset 0x10 ./l2fwd -l 4-11 -n 2
+
+.. 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
.. code-block:: console
- ./rte-app -c COREMASK [-n NUM] [-b <domain:bus:devid.func>] \
+ ./rte-app -l CORELIST [-n NUM] [-b <domain:bus:devid.func>] \
[-r NUM] [-v] [--proc-type <primary|secondary|auto>]
.. note::
The EAL options for FreeBSD are as follows:
-* ``-c COREMASK``:
+* ``-c COREMASK`` or ``-l CORELIST``:
A hexadecimal bit mask of the cores to run on. Note that core numbering
- can change between platforms and should be determined beforehand.
+ can change between platforms and should be determined beforehand. The corelist
+ is a list of cores to use instead of a core mask.
* ``-n NUM``:
Number of memory channels per processor socket.
Memory to allocate from hugepages, regardless of processor socket.
It is recommended that ``--socket-mem`` be used instead of this option.
-The ``-c`` option is mandatory; the others are optional.
+The ``-c`` or ``-l`` option is mandatory; the others are optional.
Copy the DPDK application binary to your target, then run the application
as follows (assuming the platform has four memory channels, and that cores 0-3
are present and are to be used for running the application)::
- ./helloworld -c f -n 4
+ ./helloworld -l 0-3 -n 4
.. note::
INSTALL-APP helloworld
INSTALL-MAP helloworld.map
- sudo ./build/helloworld -c F -n 2
+ sudo ./build/helloworld -l 0-3 -n 2
EAL: Contigmem driver has 2 buffers, each of size 1GB
EAL: Sysctl reports 8 cpus
.. code-block:: console
- testpmd -c 0xff -n 4 -- -i -w 01:10.0 -w 01:10.1 --forward-mode=mac
+ testpmd -l 0-7 -n 4 -- -i -w 01:10.0 -w 01:10.1 --forward-mode=mac
In this example, traffic matching the rules will go through the VF by matching
the filter rule. All other traffic, not matching the rules, will go through
.. code-block:: console
- testpmd -c 0xff -n 4 -- -i -w 01:10.0 -w 01:10.1 --forward-mode=mac
+ testpmd -l 0-7 -n 4 -- -i -w 01:10.0 -w 01:10.1 --forward-mode=mac
.. note::
# use for bonding of virtio and vf tests in VM
/root/dpdk/x86_64-default-linuxapp-gcc/app/testpmd \
- -c f -n 4 --socket-mem 350 -- --i --port-topology=chained
+ -l 0-3 -n 4 --socket-mem 350 -- --i --port-topology=chained
.. _lm_bond_virtio_sriov_switch_conf:
# test system has 8 cpus (0-7), use cpus 2-7 for VM
/root/dpdk/x86_64-default-linuxapp-gcc/app/testpmd \
- -c 3f -n 4 --socket-mem 350 -- --burst=64 --i --disable-hw-vlan-filter
+ -l 0-5 -n 4 --socket-mem 350 -- --burst=64 --i --disable-hw-vlan-filter
.. code-block:: console
- $(testpmd) -c 0xc -n 4 \
+ $(testpmd) -l 2-3 -n 4 \
--vdev=virtio_user0,path=/dev/vhost-net,queue_size=1024 \
-- -i --txqflags=0x0 --disable-hw-vlan --enable-lro --crc-strip
--enable-rx-cksum --rxd=1024 --txd=1024
.. code-block:: console
- $(testpmd) -c 0xc -n 4 \
+ $(testpmd) -l 2-3 -n 4 \
--vdev=virtio_user0,path=/dev/vhost-net,queues=2,queue_size=1024 \
-- -i --txqflags=0x0 --disable-hw-vlan --enable-lro \
--crc-strip --enable-rx-cksum --txq=2 --rxq=2 --rxd=1024 \
.. code-block:: console
- $(testpmd) -c 0x3 -n 4 --socket-mem 1024,1024 \
+ $(testpmd) -l 0-1 -n 4 --socket-mem 1024,1024 \
--vdev 'eth_vhost0,iface=/tmp/sock0' --no-pci -- -i
#. Start a container instance with a virtio-user port.
docker run -i -t -v /tmp/sock0:/var/run/usvhost \
-v /dev/hugepages:/dev/hugepages \
- dpdk-app-testpmd testpmd -c 0xc -n 4 -m 1024 --no-pci \
+ dpdk-app-testpmd testpmd -l 6-7 -n 4 -m 1024 --no-pci \
--vdev=virtio_user0,path=/var/run/usvhost \
-- -i --txqflags=0xf00 --disable-hw-vlan
.. code-block:: console
- ./rte-app -c COREMASK [-n NUM] [-b <domain:bus:devid.func>] \
+ ./rte-app [-c COREMASK | -l CORELIST] [-n NUM] [-b <domain:bus:devid.func>] \
[--socket-mem=MB,...] [-m MB] [-r NUM] [-v] [--file-prefix] \
[--proc-type <primary|secondary|auto>] [-- xen-dom0]
The EAL options are as follows:
-* ``-c COREMASK``:
+* ``-c COREMASK`` or ``-l CORELIST``:
An hexadecimal bit mask of the cores to run on. Note that core numbering can
- change between platforms and should be determined beforehand.
+ change between platforms and should be determined beforehand. The corelist is
+ a set of core numbers instead of a bitmap core mask.
* ``-n NUM``:
Number of memory channels per processor socket.
* ``--vfio-intr``:
Specify interrupt type to be used by VFIO (has no effect if VFIO is not used).
-The ``-c`` and option is mandatory; the others are optional.
+The ``-c`` or ``-l`` and option is mandatory; the others are optional.
Copy the DPDK application binary to your target, then run the application as follows
(assuming the platform has four memory channels per processor socket,
and that cores 0-3 are present and are to be used for running the application)::
- ./helloworld -c f -n 4
+ ./helloworld -l 0-3 -n 4
.. note::
Logical Core Use by Applications
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-The coremask parameter is always mandatory for DPDK applications.
-Each bit of the mask corresponds to the equivalent logical core number as reported by Linux.
+The coremask (-c 0x0f) or corelist (-l 0-3) parameter is always mandatory for DPDK applications.
+Each bit of the mask corresponds to the equivalent logical core number as reported by Linux. The preferred corelist option is a cleaner method to define cores to be used.
Since these logical core numbers, and their mapping to specific cores on specific NUMA sockets, can vary from platform to platform,
-it is recommended that the core layout for each platform be considered when choosing the coremask to use in each case.
+it is recommended that the core layout for each platform be considered when choosing the coremask/corelist to use in each case.
On initialization of the EAL layer by an DPDK application, the logical cores to be used and their socket location are displayed.
This information can also be determined for all cores on the system by examining the ``/proc/cpuinfo`` file, for example, by running cat ``/proc/cpuinfo``.
.. warning::
- The logical core layout can change between different board layouts and should be checked before selecting an application coremask.
+ The logical core layout can change between different board layouts and should be checked before selecting an application coremask/corelist.
Hugepage Memory Use by Applications
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
7. The command line of running l3fwd would be something like the followings::
- ./l3fwd -c 0x3c0000 -n 4 -w 82:00.0 -w 85:00.0 \
+ ./l3fwd -l 18-21 -n 4 -w 82:00.0 -w 85:00.0 \
-- -p 0x3 --config '(0,0,18),(0,1,19),(1,0,20),(1,1,21)'
This means that the application uses core 18 for port 0, queue pair 0 forwarding, core 19 for port 0, queue pair 1 forwarding,
INSTALL-APP helloworld
INSTALL-MAP helloworld.map
- sudo ./build/app/helloworld -c 0xf -n 3
+ sudo ./build/app/helloworld -l 0-3 -n 3
[sudo] password for rte:
EAL: coremask set to f
.. code-block:: console
- ./x86_64-native-linuxapp-gcc/app/testpmd -c 0xf -n 4 -- -i
+ ./x86_64-native-linuxapp-gcc/app/testpmd -l 0-3 -n 4 -- -i
Example output:
.. code-block:: console
- ./x86_64-native-linuxapp-gcc/app/testpmd -c 0xf -n 4 -w 0000:02:00.4 -- -i
+ ./x86_64-native-linuxapp-gcc/app/testpmd -l 0-3 -n 4 -w 0000:02:00.4 -- -i
Example output:
.. code-block:: console
- ./x86_64-native-bsdapp-clang/app/testpmd -c 0xf -n 4 -w 0000:02:00.4 -- -i
+ ./x86_64-native-bsdapp-clang/app/testpmd -l 0-3 -n 4 -w 0000:02:00.4 -- -i
Example output:
.. code-block:: console
- ./x86_64-native-linuxapp-gcc/app/testpmd -c 0xf -n 4 -- -i
+ ./x86_64-native-linuxapp-gcc/app/testpmd -l 0-3 -n 4 -- -i
Example output:
.. code-block:: console
- ./x86_64-native-linuxapp-gcc/app/testpmd -c 0xf -n 4 -w 83:00.0 -- -i
+ ./x86_64-native-linuxapp-gcc/app/testpmd -l 0-3 -n 4 -w 83:00.0 -- -i
Example output:
.. code-block:: console
- ./app/testpmd -c ffff -n 4 -- -i --forward-mode=mac
+ ./app/testpmd -l 0-15 -n 4 -- -i --forward-mode=mac
...
testpmd> set promisc 0 off
.. code-block:: console
- ./app/testpmd -c ffff -n 4 -- -i --disable-rss --pkt-filter-mode=perfect \
+ ./app/testpmd -l 0-15 -n 4 -- -i --disable-rss --pkt-filter-mode=perfect \
--rxq=8 --txq=8 --nb-cores=8 --nb-ports=1
Add a rule to direct ``ipv4-udp`` packet whose ``dst_ip=2.2.2.5, src_ip=2.2.2.3, src_port=32, dst_port=32`` to queue 1:
.. code-block:: console
- testpmd -c 0xffff -n 4 -- --coremask=<core-mask> --rxq=4 --txq=4 -i
+ testpmd -l 0-15 -n 4 -- --coremask=<core-mask> --rxq=4 --txq=4 -i
+
+.. Note: The preferred option is -c XX or -l n-n,n instead of a coremask value. The --coremask option
+ is a feature of the application and not DPDK EAL options.
The limitation for VF RSS on Intel® 82599 10 Gigabit Ethernet Controller is:
The hash and key are shared among PF and all VF, the RETA table with 128 entries is also shared
.. code-block:: console
make install T=x86_64-native-linuxapp-gcc
- ./x86_64-native-linuxapp-gcc/app/testpmd -c f -n 4 -- -i
+ ./x86_64-native-linuxapp-gcc/app/testpmd -l 0-3 -n 4 -- -i
#. Finally, access the Guest OS using vncviewer with the localhost:5900 port and check the lspci command output in the Guest OS.
The virtual functions will be listed as available for use.
.. code-block:: console
- ./x86_64-native-linuxapp-gcc/app/testpmd -c 300 -n 4 -- -i --burst=32 --rxfreet=32 --mbcache=250 --txpt=32 --rxht=8 --rxwt=0 --txfreet=32 --txrst=32 --txqflags=0xf01
+ ./x86_64-native-linuxapp-gcc/app/testpmd -l 8-9 -n 4 -- -i --burst=32 --rxfreet=32 --mbcache=250 --txpt=32 --rxht=8 --rxwt=0 --txfreet=32 --txrst=32 --txqflags=0xf01
When CONFIG_RTE_IXGBE_RX_OLFLAGS_ENABLE=n, better performance can be achieved:
.. code-block:: console
- ./x86_64-native-linuxapp-gcc/app/testpmd -c 300 -n 4 -- -i --burst=32 --rxfreet=32 --mbcache=250 --txpt=32 --rxht=8 --rxwt=0 --txfreet=32 --txrst=32 --txqflags=0xf01 --disable-hw-vlan
+ ./x86_64-native-linuxapp-gcc/app/testpmd -l 8-9 -n 4 -- -i --burst=32 --rxfreet=32 --mbcache=250 --txpt=32 --rxht=8 --rxwt=0 --txfreet=32 --txrst=32 --txqflags=0xf01 --disable-hw-vlan
l3fwd
~~~~~
.. code-block:: console
- testpmd -c 0xff00 -n 4 -w 0000:83:00.0 -w 0000:84:00.0 -- --rxq=2 --txq=2 -i
+ testpmd -l 8-15 -n 4 -w 0000:83:00.0 -w 0000:84:00.0 -- --rxq=2 --txq=2 -i
Example output:
.. code-block:: console
- testpmd -c 0xff00 -n 4 -w 05:00.0 -w 05:00.1 -w 06:00.0 -w 06:00.1 -- --rxq=2 --txq=2 -i
+ testpmd -l 8-15 -n 4 -w 05:00.0 -w 05:00.1 -w 06:00.0 -w 06:00.1 -- --rxq=2 --txq=2 -i
Example output:
.. code-block:: console
- $RTE_TARGET/app/testpmd -c f -n 4 \
+ $RTE_TARGET/app/testpmd -l 0-3 -n 4 \
--vdev 'net_pcap0,stream_opt0=..,stream_opt1=..' \
--vdev='net_pcap1,stream_opt0=..'
.. code-block:: console
- $RTE_TARGET/app/testpmd -c '0xf' -n 4 \
+ $RTE_TARGET/app/testpmd -l 0-3 -n 4 \
--vdev 'net_pcap0,rx_pcap=file_rx.pcap,tx_pcap=file_tx.pcap' \
-- --port-topology=chained
.. code-block:: console
- $RTE_TARGET/app/testpmd -c '0xf' -n 4 \
+ $RTE_TARGET/app/testpmd -l 0-3 -n 4 \
--vdev 'net_pcap0,rx_iface=eth0,tx_pcap=file_tx.pcap' \
-- --port-topology=chained
.. code-block:: console
- $RTE_TARGET/app/testpmd -c '0xf' -n 4 \
+ $RTE_TARGET/app/testpmd -l 0-3 -n 4 \
--vdev 'net_pcap0,rx_pcap=file_rx.pcap,tx_iface=eth1' \
-- --port-topology=chained
.. code-block:: console
- $RTE_TARGET/app/testpmd -c '0xf' -n 4 \
+ $RTE_TARGET/app/testpmd -l 0-3 -n 4 \
--vdev 'net_pcap0,iface=eth0' --vdev='net_pcap1;iface=eth1'
Using libpcap-based PMD with the testpmd Application
.. code-block:: console
- $RTE_TARGET/app/testpmd -c '0xf' -n 4 \
+ $RTE_TARGET/app/testpmd -l 0-3 -n 4 \
--vdev 'net_pcap0,rx_pcap=file_rx.pcap,tx_pcap=file_tx.pcap' \
-- --port-topology=chained --no-flush-rx
.. code-block:: console
- ./testpmd -c E -n 4 --vdev=net_ring0 --vdev=net_ring1 -- -i
+ ./testpmd -l 1-3 -n 4 --vdev=net_ring0 --vdev=net_ring1 -- -i
EAL: Detected lcore 1 as core 1 on socket 0
...
.. code-block:: console
- testpmd -c 0xff1 -n 4 -- -i --nb-cores=8 --portmask=0xf --rxd=4096 \
+ testpmd -l 0,4-11 -n 4 -- -i --nb-cores=8 --portmask=0xf --rxd=4096 \
--txd=4096 --txfreet=4068 --enable-rx-cksum --rxq=4 --txq=4 \
--rss-ip --rss-udp
.. code-block:: console
- $RTE_TARGET/app/testpmd -c 0xf -n 2 \
+ $RTE_TARGET/app/testpmd -l 0-3 -n 2 \
-- --port-topology=chained --rxq=2 --txq=2 --nb-cores=2 -i -a
Example output:
.. code-block:: console
- ./arm64-thunderx-linuxapp-gcc/app/testpmd -c 0xf -n 4 -w 0002:01:00.2 \
+ ./arm64-thunderx-linuxapp-gcc/app/testpmd -l 0-3 -n 4 -w 0002:01:00.2 \
-- -i --disable-hw-vlan-filter --crc-strip --no-flush-rx \
--port-topology=loop
.. code-block:: console
- ./testpmd -c f -n 4 --vdev 'net_vhost0,iface=/tmp/sock0,queues=1' -- -i
+ ./testpmd -l 0-3 -n 4 --vdev 'net_vhost0,iface=/tmp/sock0,queues=1' -- -i
Other basic DPDK preparations like hugepage enabling here.
Please refer to the *DPDK Getting Started Guide* for detailed instructions.
.. code-block:: console
- examples/kni/build/app/kni -c 0xf -n 4 -- -p 0x1 -P --config="(0,1,3)"
+ examples/kni/build/app/kni -l 0-3 -n 4 -- -p 0x1 -P --config="(0,1,3)"
This command generates one network device vEth0 for physical port.
If specify more physical ports, the generated network device will be vEth1, vEth2, and so on.
Example of using the vector version of the virtio poll mode driver in
``testpmd``::
- testpmd -c 0x7 -n 4 -- -i --txqflags=0xF01 --rxq=1 --txq=1 --nb-cores=1
+ testpmd -l 0-2 -n 4 -- -i --txqflags=0xF01 --rxq=1 --txq=1 --nb-cores=1
Interrupt mode
.. code-block:: console
- $ l3fwd-power -c 0x3 -- -p 1 -P --config="(0,0,1)" \
+ $ l3fwd-power -l 0-1 -- -p 1 -P --config="(0,0,1)" \
--no-numa --parse-ptype
.. code-block:: console
- $RTE_TARGET/app/testpmd -c f -n 4 --vdev 'net_bond0,bond_opt0=..,bond opt1=..'--vdev 'net_bond1,bond _opt0=..,bond_opt1=..'
+ $RTE_TARGET/app/testpmd -l 0-3 -n 4 --vdev 'net_bond0,bond_opt0=..,bond opt1=..'--vdev 'net_bond1,bond _opt0=..,bond_opt1=..'
Link Bonding EAL Options
^^^^^^^^^^^^^^^^^^^^^^^^
.. code-block:: console
- $RTE_TARGET/app/testpmd -c '0xf' -n 4 --vdev 'net_bond0,mode=0, slave=0000:00a:00.01,slave=0000:004:00.00' -- --port-topology=chained
+ $RTE_TARGET/app/testpmd -l 0-3 -n 4 --vdev 'net_bond0,mode=0, slave=0000:00a:00.01,slave=0000:004:00.00' -- --port-topology=chained
Create a bonded device in round robin mode with two slaves specified by their PCI address and an overriding MAC address:
.. code-block:: console
- $RTE_TARGET/app/testpmd -c '0xf' -n 4 --vdev 'net_bond0,mode=0, slave=0000:00a:00.01,slave=0000:004:00.00,mac=00:1e:67:1d:fd:1d' -- --port-topology=chained
+ $RTE_TARGET/app/testpmd -l 0-3 -n 4 --vdev 'net_bond0,mode=0, slave=0000:00a:00.01,slave=0000:004:00.00,mac=00:1e:67:1d:fd:1d' -- --port-topology=chained
Create a bonded device in active backup mode with two slaves specified, and a primary slave specified by their PCI addresses:
.. code-block:: console
- $RTE_TARGET/app/testpmd -c '0xf' -n 4 --vdev 'net_bond0,mode=1, slave=0000:00a:00.01,slave=0000:004:00.00,primary=0000:00a:00.01' -- --port-topology=chained
+ $RTE_TARGET/app/testpmd -l 0-3 -n 4 --vdev 'net_bond0,mode=1, slave=0000:00a:00.01,slave=0000:004:00.00,primary=0000:00a:00.01' -- --port-topology=chained
Create a bonded device in balance mode with two slaves specified by their PCI addresses, and a transmission policy of layer 3 + 4 forwarding:
.. code-block:: console
- $RTE_TARGET/app/testpmd -c '0xf' -n 4 --vdev 'net_bond0,mode=2, slave=0000:00a:00.01,slave=0000:004:00.00,xmit_policy=l34' -- --port-topology=chained
+ $RTE_TARGET/app/testpmd -l 0-3 -n 4 --vdev 'net_bond0,mode=2, slave=0000:00a:00.01,slave=0000:004:00.00,xmit_policy=l34' -- --port-topology=chained
so it is recommended that it be disabled only when absolutely necessary,
and only when the implications of this change have been understood.
-* All DPDK processes running as a single application and using shared memory must have distinct coremask arguments.
+* All DPDK processes running as a single application and using shared memory must have distinct coremask/corelist arguments.
It is not possible to have a primary and secondary instance, or two secondary instances,
using any of the same logical cores.
Attempting to do so can cause corruption of memory pool caches, among other issues.
.. code-block:: console
- $ ./build/cmdline -c f -n 4
+ $ ./build/cmdline -l 0-3 -n 4
Refer to the *DPDK Getting Started Guide* for general information on running applications
and the Environment Abstraction Layer (EAL) options.
.. code-block:: console
- $ ./build/distributor_app -c 0x4003fe -n 4 -- -p f
+ $ ./build/distributor_app -l 1-9,22 -n 4 -- -p f
#. Refer to the DPDK Getting Started Guide for general information on running
applications and the Environment Abstraction Layer (EAL) options.
and the Environment Abstraction Layer (EAL) options.
The number of bits set in each bitmask must be the same.
-The coremask -c parameter of the EAL options should include IN_CORES and OUT_CORES.
+The coremask -c or the corelist -l parameter of the EAL options should include IN_CORES and OUT_CORES.
The same bit must not be set in IN_CORES and OUT_CORES.
The affinities between ports and cores are set beginning with the least significant bit of each mask, that is,
the port represented by the lowest bit in PORTMASK is read from by the core represented by the lowest bit in IN_CORES,
.. code-block:: console
- ./build/exception_path -c f -n 4 -- -p 3 -i 3 -o c
+ ./build/exception_path -l 0-3 -n 4 -- -p 3 -i 3 -o c
Getting Statistics
~~~~~~~~~~~~~~~~~~
.. code-block:: console
- $ ./build/helloworld -c f -n 4
+ $ ./build/helloworld -l 0-3 -n 4
Refer to *DPDK Getting Started Guide* for general information on running applications
and the Environment Abstraction Layer (EAL) options.
.. code-block:: console
- ./build/dpdk_qat -c 0xff -n 2 -- -p 0x3 --config '(0,0,1),(1,0,2)'
+ ./build/dpdk_qat -l 0-7 -n 2 -- -p 0x3 --config '(0,0,1),(1,0,2)'
Refer to the *DPDK Test Report* for more examples of traffic generator setup and the application startup command lines.
If no errors are generated in response to the startup commands, the application is running correctly.
.. code-block:: console
- ./build/ip_fragmentation -c 0x14 -n 3 -- -p 5
+ ./build/ip_fragmentation -l 2,4 -n 3 -- -p 5
EAL: coremask set to 14
EAL: Detected lcore 0 on socket 0
EAL: Detected lcore 1 on socket 1
.. code-block:: console
- ./build/ip_fragmentation -c 0x10 -n 3 -- -p 5 -q 2
+ ./build/ip_fragmentation -l 4 -n 3 -- -p 5 -q 2
To test the application, flows should be set up in the flow generator that match the values in the
l3fwd_ipv4_route_array and/or l3fwd_ipv6_route_array table.
.. code-block:: console
- ./build/ip_reassembly -c 0x14 -n 3 -- -p 5
+ ./build/ip_reassembly -l 2,4 -n 3 -- -p 5
EAL: coremask set to 14
EAL: Detected lcore 0 on socket 0
EAL: Detected lcore 1 on socket 1
.. code-block:: console
- ./build/ip_reassembly -c 0x10 -n 3 -- -p 5 -q 2
+ ./build/ip_reassembly -l 4 -n 3 -- -p 5 -q 2
To test the application, flows should be set up in the flow generator that match the values in the
l3fwd_ipv4_route_array and/or l3fwd_ipv6_route_array table.
.. code-block:: console
- ./build/ipv4_multicast -c 0x00f -n 3 -- -p 0x3 -q 1
+ ./build/ipv4_multicast -l 0-3 -n 3 -- -p 0x3 -q 1
In this command:
.. code-block:: console
- ./build/l2fwd-keepalive -c f -n 4 -- -q 8 -p ffff -K 10
+ ./build/l2fwd-keepalive -l 0-3 -n 4 -- -q 8 -p ffff -K 10
Refer to the *DPDK Getting Started Guide* for general information on
running applications and the Environment Abstraction Layer (EAL)
Refer to *DPDK Getting Started Guide* for general information on running applications and the Environment Abstraction Layer (EAL) options.
-The -c coremask parameter of the EAL options should include the lcores indicated by the lcore_rx and lcore_tx,
+The -c coremask or -l corelist parameter of the EAL options should include the lcores indicated by the lcore_rx and lcore_tx,
but does not need to include lcores indicated by lcore_kthread as they are used to pin the kernel thread on.
The -p PORTMASK parameter should include the ports indicated by the port in --config, neither more nor less.
.. code-block:: console
- ./build/kni -c 0xf0 -n 4 -- -P -p 0x3 -config="(0,4,6,8),(1,5,7,9)"
+ ./build/kni -l 4-7 -n 4 -- -P -p 0x3 -config="(0,4,6,8),(1,5,7,9)"
KNI Operations
--------------
.. code-block:: console
- ./build/l2fwd-cat -c 2 -n 4 -- --l3ca="0x3@(0-2)"
+ ./build/l2fwd-cat -l 1 -n 4 -- --l3ca="0x3@(0-2)"
or to enable CAT and CDP on cpus 1,3:
.. code-block:: console
- ./build/l2fwd-cat -c 2 -n 4 -- --l3ca="(0x00C00,0x00300)@(1,3)"
+ ./build/l2fwd-cat -l 1 -n 4 -- --l3ca="(0x00C00,0x00300)@(1,3)"
If CDP is not supported it will fail with following error message:
``atexit(...)`` is used to register ``cat_exit(...)`` to be called on
a clean exit. ``cat_exit(...)`` performs a simple CAT clean-up, by associating
-COS 0 to all involved CPUs via ``pqos_l3ca_assoc_set(...)`` calls.
\ No newline at end of file
+COS 0 to all involved CPUs via ``pqos_l3ca_assoc_set(...)`` calls.
.. code-block:: console
- $ ./build/l2fwd-crypto -c 0x3 -n 4 --vdev "cryptodev_aesni_mb_pmd" \
+ $ ./build/l2fwd-crypto -l 0-1 -n 4 --vdev "cryptodev_aesni_mb_pmd" \
--vdev "cryptodev_aesni_mb_pmd" -- -p 0x3 --chain CIPHER_HASH \
--cipher_op ENCRYPT --cipher_algo AES_CBC \
--cipher_key 00:01:02:03:04:05:06:07:08:09:0a:0b:0c:0d:0e:0f \
.. code-block:: console
- $ ./build/l2fwd-jobstats -c f -n 4 -- -q 8 -p ffff -l
+ $ ./build/l2fwd-jobstats -l 0-3 -n 4 -- -q 8 -p ffff -l
Refer to the *DPDK Getting Started Guide* for general information on running applications
and the Environment Abstraction Layer (EAL) options.
.. code-block:: console
- $ ./build/l2fwd -c f -n 4 -- -q 8 -p ffff
+ $ ./build/l2fwd -l 0-3 -n 4 -- -q 8 -p ffff
Refer to the *DPDK Getting Started Guide* for general information on running applications
and the Environment Abstraction Layer (EAL) options.
In this command:
-* The -c option enables cores 1, 2
+* The -l option enables cores 1, 2
* The -p option enables ports 0 and 1
.. code-block:: console
- $ ./build/link_status_interrupt -c f -n 4-- -q 8 -p ffff
+ $ ./build/link_status_interrupt -l 0-3 -n 4-- -q 8 -p ffff
Refer to the *DPDK Getting Started Guide* for general information on running applications
and the Environment Abstraction Layer (EAL) options.
.. code-block:: console
- ./load_balancer -c 0xf8 -n 4 -- --rx "(0,0,3),(1,0,3)" --tx "(0,3),(1,3)" --w "4,5,6,7" --lpm "1.0.0.0/24=>0; 1.0.1.0/24=>1;" --pos-lb 29
+ ./load_balancer -l 3-7 -n 4 -- --rx "(0,0,3),(1,0,3)" --tx "(0,3),(1,3)" --w "4,5,6,7" --lpm "1.0.0.0/24=>0; 1.0.1.0/24=>1;" --pos-lb 29
There is a single I/O lcore (lcore 3) that handles RX and TX for two NIC ports (ports 0 and 1) that
handles packets to/from four worker lcores (lcores 4, 5, 6 and 7) that
^^^^^^^^^^^^^^^^^^^^^^^
To run the application, start one copy of the simple_mp binary in one terminal,
-passing at least two cores in the coremask, as follows:
+passing at least two cores in the coremask/corelist, as follows:
.. code-block:: console
- ./build/simple_mp -c 3 -n 4 --proc-type=primary
+ ./build/simple_mp -l 0-1 -n 4 --proc-type=primary
For the first DPDK process run, the proc-type flag can be omitted or set to auto,
since all DPDK processes will default to being a primary instance,
.. code-block:: console
- $ ./build/simple_mp -c 3 -n 4 --proc-type=primary
+ $ ./build/simple_mp -l 0-1 -n 4 --proc-type=primary
EAL: coremask set to 3
EAL: Detected lcore 0 on socket 0
EAL: Detected lcore 1 on socket 0
simple_mp >
To run the secondary process to communicate with the primary process,
-again run the same binary setting at least two cores in the coremask:
+again run the same binary setting at least two cores in the coremask/corelist:
.. code-block:: console
- ./build/simple_mp -c C -n 4 --proc-type=secondary
+ ./build/simple_mp -l 2-3 -n 4 --proc-type=secondary
When running a secondary process such as that shown above, the proc-type parameter can again be specified as auto.
However, omitting the parameter altogether will cause the process to try and start as a primary rather than secondary process.
.. code-block:: console
- # ./build/symmetric_mp -c 2 -n 4 --proc-type=auto -- -p 3 --num-procs=4 --proc-id=0
- # ./build/symmetric_mp -c 4 -n 4 --proc-type=auto -- -p 3 --num-procs=4 --proc-id=1
- # ./build/symmetric_mp -c 8 -n 4 --proc-type=auto -- -p 3 --num-procs=4 --proc-id=2
- # ./build/symmetric_mp -c 10 -n 4 --proc-type=auto -- -p 3 --num-procs=4 --proc-id=3
+ # ./build/symmetric_mp -l 1 -n 4 --proc-type=auto -- -p 3 --num-procs=4 --proc-id=0
+ # ./build/symmetric_mp -l 2 -n 4 --proc-type=auto -- -p 3 --num-procs=4 --proc-id=1
+ # ./build/symmetric_mp -l 3 -n 4 --proc-type=auto -- -p 3 --num-procs=4 --proc-id=2
+ # ./build/symmetric_mp -l 4 -n 4 --proc-type=auto -- -p 3 --num-procs=4 --proc-id=3
.. note::
.. note::
- In the server process, a single thread, the master thread, that is, the lowest numbered lcore in the coremask, performs all packet I/O.
- If a coremask is specified with more than a single lcore bit set in it,
+ In the server process, a single thread, the master thread, that is, the lowest numbered lcore in the coremask/corelist, performs all packet I/O.
+ If a coremask/corelist is specified with more than a single lcore bit set in it,
an additional lcore will be used for a thread to periodically print packet count statistics.
Since the server application stores configuration data in shared memory, including the network ports to be used,
.. code-block:: console
- # ./mp_server/build/mp_server -c 6 -n 4 -- -p 3 -n 2
- # ./mp_client/build/mp_client -c 8 -n 4 --proc-type=auto -- -n 0
- # ./mp_client/build/mp_client -c 10 -n 4 --proc-type=auto -- -n 1
+ # ./mp_server/build/mp_server -l 1-2 -n 4 -- -p 3 -n 2
+ # ./mp_client/build/mp_client -l 3 -n 4 --proc-type=auto -- -n 0
+ # ./mp_client/build/mp_client -l 4 -n 4 --proc-type=auto -- -n 1
.. note::
.. code-block:: console
- #./build/l2fwd_fork -c 1c -n 4 -- -p 3 -f
+ #./build/l2fwd_fork -l 2-4 -n 4 -- -p 3 -f
This example provides another -f option to specify the use of floating process.
If not specified, the example will use a pinned process to perform the L2 forwarding task.
For example, the following places every l-thread on different lcores::
- l3fwd-thread -c ff -n 2 -- -P -p 3 \
+ l3fwd-thread -l 0-7 -n 2 -- -P -p 3 \
--rx="(0,0,0,0)(1,0,1,1)" \
--tx="(2,0)(3,1)"
The following places RX l-threads on lcore 0 and TX l-threads on lcore 1 and 2
and so on::
- l3fwd-thread -c ff -n 2 -- -P -p 3 \
+ l3fwd-thread -l 0-7 -n 2 -- -P -p 3 \
--rx="(0,0,0,0)(1,0,0,1)" \
--tx="(1,0)(2,1)"
For example, the following places every EAL thread on different lcores::
- l3fwd-thread -c ff -n 2 -- -P -p 3 \
+ l3fwd-thread -l 0-7 -n 2 -- -P -p 3 \
--rx="(0,0,0,0)(1,0,1,1)" \
--tx="(2,0)(3,1)" \
--no-lthreads
The following places RX EAL threads on lcore 0 and TX EAL threads on lcore 1
and 2 and so on::
- l3fwd-thread -c ff -n 2 --lcores="(0,1)@0,(2,3)@1" -- -P -p 3 \
+ l3fwd-thread -l 0-7 -n 2 --lcores="(0,1)@0,(2,3)@1" -- -P -p 3 \
--rx="(0,0,0,0)(1,0,1,1)" \
--tx="(2,0)(3,1)" \
--no-lthreads
a) Start every thread on different scheduler (1:1)::
- l3fwd-thread -c ff -n 2 -- -P -p 3 \
+ l3fwd-thread -l 0-7 -n 2 -- -P -p 3 \
--rx="(0,0,0,0)(1,0,1,1)" \
--tx="(2,0)(3,1)"
EAL thread equivalent::
- l3fwd-thread -c ff -n 2 -- -P -p 3 \
+ l3fwd-thread -l 0-7 -n 2 -- -P -p 3 \
--rx="(0,0,0,0)(1,0,1,1)" \
--tx="(2,0)(3,1)" \
--no-lthreads
Start 4 L-threads on lcore 0::
- l3fwd-thread -c ff -n 2 -- -P -p 3 \
+ l3fwd-thread -l 0-7 -n 2 -- -P -p 3 \
--rx="(0,0,0,0)(1,0,0,1)" \
--tx="(0,0)(0,1)"
Start 4 EAL threads on cpu-set 0::
- l3fwd-thread -c ff -n 2 --lcores="(0-3)@0" -- -P -p 3 \
+ l3fwd-thread -l 0-7 -n 2 --lcores="(0-3)@0" -- -P -p 3 \
--rx="(0,0,0,0)(1,0,0,1)" \
--tx="(2,0)(3,1)" \
--no-lthreads
Start 2 L-threads for RX on lcore 0, and 2 L-threads for TX on lcore 1::
- l3fwd-thread -c ff -n 2 -- -P -p 3 \
+ l3fwd-thread -l 0-7 -n 2 -- -P -p 3 \
--rx="(0,0,0,0)(1,0,0,1)" \
--tx="(1,0)(1,1)"
Start 2 EAL threads for RX on cpu-set 0, and 2 EAL threads for TX on
cpu-set 1::
- l3fwd-thread -c ff -n 2 --lcores="(0-1)@0,(2-3)@1" -- -P -p 3 \
+ l3fwd-thread -l 0-7 -n 2 --lcores="(0-1)@0,(2-3)@1" -- -P -p 3 \
--rx="(0,0,0,0)(1,0,1,1)" \
--tx="(2,0)(3,1)" \
--no-lthreads
.. code-block:: console
- ./build/ptpclient -c 2 -n 4 -- -p 0x1 -T 0
+ ./build/ptpclient -l 1 -n 4 -- -p 0x1 -T 0
Refer to *DPDK Getting Started Guide* for general information on running
applications and the Environment Abstraction Layer (EAL) options.
.. code-block:: console
- ./qos_sched -c a2 -n 4 -- --pfc "3,2,5,7" --cfg ./profile.cfg
+ ./qos_sched -l 1,5,7 -n 4 -- --pfc "3,2,5,7" --cfg ./profile.cfg
This example uses a single packet flow configuration which creates one RX thread on lcore 5 reading
from port 3 and a worker thread on lcore 7 writing to port 2.
.. code-block:: console
- ./qos_sched -c c6 -n 4 -- --pfc "3,2,2,6,7" --pfc "1,0,2,6,7" --cfg ./profile.cfg
+ ./qos_sched -l 1,2,6,7 -n 4 -- --pfc "3,2,2,6,7" --pfc "1,0,2,6,7" --cfg ./profile.cfg
Note that independent cores for the packet flow configurations for each of the RX, WT and TX thread are also supported,
providing flexibility to balance the work.
-The EAL coremask is constrained to contain the default mastercore 1 and the RX, WT and TX cores only.
+The EAL coremask/corelist is constrained to contain the default mastercore 1 and the RX, WT and TX cores only.
Explanation
-----------
.. code-block:: console
- ./qw/build/qw -c f -n 4 -- -p 5
+ ./qw/build/qw -l 0-3 -n 4 -- -p 5
Refer to the *DPDK Getting Started Guide* for general information on running applications and
the Environment Abstraction Layer (EAL) options.
.. code-block:: console
- ./qwctl/build/qwctl -c 1 -n 4 --proc-type=secondary
+ ./qwctl/build/qwctl -l 0 -n 4 --proc-type=secondary
Refer to the *DPDK Getting Started* Guide for general information on running applications and
the Environment Abstraction Layer (EAL) options.
.. code-block:: console
- ./build/rxtx_callbacks -c 2 -n 4
+ ./build/rxtx_callbacks -l 1 -n 4
Refer to *DPDK Getting Started Guide* for general information on running
applications and the Environment Abstraction Layer (EAL) options.
.. code-block:: console
- ./build/basicfwd -c 2 -n 4
+ ./build/basicfwd -l 1 -n 4
Refer to *DPDK Getting Started Guide* for general information on running
applications and the Environment Abstraction Layer (EAL) options.
.. code-block:: console
- user@target:~$ ./build/app/tep_termination -c f -n 4 --huge-dir /mnt/huge --
+ user@target:~$ ./build/app/tep_termination -l 0-3 -n 4 --huge-dir /mnt/huge --
-p 0x1 --dev-basename tep-termination --nb-devices 4
--udp-port 4789 --filter-type 1
.. code-block:: console
- user@target:~$ ./build/app/tep_termination -c f -n 4 --huge-dir /mnt/huge --
+ user@target:~$ ./build/app/tep_termination -l 0-3 -n 4 --huge-dir /mnt/huge --
--nb-devices 2
**Tunneling UDP port.**
.. code-block:: console
- user@target:~$ ./build/app/tep_termination -c f -n 4 --huge-dir /mnt/huge --
+ user@target:~$ ./build/app/tep_termination -l 0-3 -n 4 --huge-dir /mnt/huge --
--nb-devices 2 --udp-port 4789
**Filter Type.**
.. code-block:: console
- user@target:~$ ./build/app/tep_termination -c f -n 4 --huge-dir /mnt/huge --
+ user@target:~$ ./build/app/tep_termination -l 0-3 -n 4 --huge-dir /mnt/huge --
--nb-devices 2 --udp-port 4789 --filter-type 1
**TX Checksum.**
.. code-block:: console
- user@target:~$ ./build/app/tep_termination -c f -n 4 --huge-dir /mnt/huge --
+ user@target:~$ ./build/app/tep_termination -l 0-3 -n 4 --huge-dir /mnt/huge --
--nb-devices 2 --tx-checksum
**TCP segment size.**
.. code-block:: console
- user@target:~$ ./build/app/tep_termination -c f -n 4 --huge-dir /mnt/huge --
+ user@target:~$ ./build/app/tep_termination -l 0-3 -n 4 --huge-dir /mnt/huge --
--tx-checksum --tso-segsz 800
**Decapsulation option.**
.. code-block:: console
- user@target:~$ ./build/app/tep_termination -c f -n 4 --huge-dir /mnt/huge --
+ user@target:~$ ./build/app/tep_termination -l 0-3 -n 4 --huge-dir /mnt/huge --
--nb-devices 4 --udp-port 4789 --decap 1
**Encapsulation option.**
.. code-block:: console
- user@target:~$ ./build/app/tep_termination -c f -n 4 --huge-dir /mnt/huge --
+ user@target:~$ ./build/app/tep_termination -l 0-3 -n 4 --huge-dir /mnt/huge --
--nb-devices 4 --udp-port 4789 --encap 1
./test-pipeline [EAL options] -- -p PORTMASK --TABLE_TYPE
-The -c EAL CPU core mask option has to contain exactly 3 CPU cores.
+The -c or -l EAL CPU coremask/corelist option has to contain exactly 3 CPU cores.
The first CPU core in the core mask is assigned for core A, the second for core B and the third for core C.
The PORTMASK parameter must contain 2 or 4 ports.
.. code-block:: console
- $ ./build/timer -c f -n 4
+ $ ./build/timer -l 0-3 -n 4
Refer to the *DPDK Getting Started Guide* for general information on running applications and
the Environment Abstraction Layer (EAL) options.
.. code-block:: console
- ./vhost-switch -c f -n 4 --socket-mem 1024 \
+ ./vhost-switch -l 0-3 -n 4 --socket-mem 1024 \
-- --socket-file /tmp/sock0 --client \
...
.. code-block:: console
- ./x86_64-native-gcc/app/testpmd -c 0x3 -- -i
+ ./x86_64-native-gcc/app/testpmd -l 0-1 -- -i
> start tx_first
Inject packets
.. code-block:: console
- ./build/vm_power_mgr -c 0x3 -n 4
+ ./build/vm_power_mgr -l 0-1 -n 4
After successful initialization the user is presented with VM Power Manager CLI:
.. code-block:: console
- ./build/guest_vm_power_mgr -c 0xf -n 4
+ ./build/guest_vm_power_mgr -l 0-3 -n 4
After successful initialization the user is presented with VM Power Manager Guest CLI:
.. code-block:: console
- user@target:~$ ./build/vmdq_dcb -c f -n 4 -- -p 0x3 --nb-pools 32 --nb-tcs 4
+ user@target:~$ ./build/vmdq_dcb -l 0-3 -n 4 -- -p 0x3 --nb-pools 32 --nb-tcs 4
Refer to the *DPDK Getting Started Guide* for general information on running applications and
the Environment Abstraction Layer (EAL) options.
.. code-block:: console
- sudo ./testpmd -c 0xF -n 4 -- -i --portmask=0x1 --nb-cores=2
+ sudo ./testpmd -l 0-3 -n 4 -- -i --portmask=0x1 --nb-cores=2
The commandline options are:
with the ``dpdk-test-crypto-perf`` applcation.
See the DPDK Getting Started Guides for more information on these options.
-* ``-c <COREMASK>``
+* ``-c <COREMASK>`` or ``-l <CORELIST>``
- Set the hexadecimal bitmask of the cores to run on.
+ Set the hexadecimal bitmask of the cores to run on. The corelist is a
+ list cores to use.
* ``-w <PCI>``
for cipher encryption aes-cbc and auth generation sha1-hmac,
one milion operations, burst size 32, packet size 64::
- dpdk-test-crypto-perf -c 0xc0 --vdev crypto_aesni_mb_pmd -w 0000:00:00.0 --
+ dpdk-test-crypto-perf -l 6-7 --vdev crypto_aesni_mb_pmd -w 0000:00:00.0 --
--ptest throughput --devtype crypto_aesni_mb --optype cipher-then-auth
--cipher-algo aes-cbc --cipher-op encrypt --cipher-key-sz 16 --auth-algo
sha1-hmac --auth-op generate --auth-key-sz 64 --auth-digest-sz 12
Call application for performance latency test of two Aesni MB PMD executed
on two cores for cipher encryption aes-cbc, ten operations in silent mode::
- dpdk-test-crypto-perf -c 0xf0 --vdev crypto_aesni_mb_pmd1
+ dpdk-test-crypto-perf -l 4-7 --vdev crypto_aesni_mb_pmd1
--vdev crypto_aesni_mb_pmd2 -w 0000:00:00.0 -- --devtype crypto_aesni_mb
--cipher-algo aes-cbc --cipher-key-sz 16 --cipher-iv-sz 16
--cipher-op encrypt --optype cipher-only --silent
in silent mode, test vector provide in file "test_aes_gcm.data"
with packet verification::
- dpdk-test-crypto-perf -c 0xf0 --vdev crypto_openssl -w 0000:00:00.0 --
+ dpdk-test-crypto-perf -l 4-7 --vdev crypto_openssl -w 0000:00:00.0 --
--devtype crypto_openssl --cipher-algo aes-gcm --cipher-key-sz 16
--cipher-iv-sz 16 --cipher-op encrypt --auth-algo aes-gcm --auth-key-sz 16
--auth-digest-sz 16 --auth-aad-sz 16 --auth-op generate --optype aead
.. code-block:: console
- examples/vhost_xen/build/vhost-switch -c f -n 3 --xen-dom0 -- -p1
+ examples/vhost_xen/build/vhost-switch -l 0-3 -n 3 --xen-dom0 -- -p1
.. note::
.. code-block:: console
- ./x86_64-native-linuxapp-gcc/app/testpmd -c f -n 4 --vdev="net_xenvirt0,mac=00:00:00:00:00:11"
+ ./x86_64-native-linuxapp-gcc/app/testpmd -l 0-3 -n 4 --vdev="net_xenvirt0,mac=00:00:00:00:00:11"
testpmd>set fwd mac
testpmd>start
.. code-block:: console
- ./x86_64-native-linuxapp-gcc/app/testpmd -c f -n 4 --vdev="net_xenvirt0,mac=00:00:00:00:00:11" -- -i --eth-peer=0,00:00:00:00:00:22
+ ./x86_64-native-linuxapp-gcc/app/testpmd -l 0-3 -n 4 --vdev="net_xenvirt0,mac=00:00:00:00:00:11" -- -i --eth-peer=0,00:00:00:00:00:22
testpmd> set fwd mac
testpmd> start
.. code-block:: console
- ./x86_64-native-linuxapp-gcc/app/testpmd -c f -n 4 --vdev="net_xenvirt0,mac=00:00:00:00:00:11" -- -i --eth-peer=0,00:00:00:00:00:22 -- -i
+ ./x86_64-native-linuxapp-gcc/app/testpmd -l 0-3 -n 4 --vdev="net_xenvirt0,mac=00:00:00:00:00:11" -- -i --eth-peer=0,00:00:00:00:00:22 -- -i
Run TestPMD in guest VM2:
.. code-block:: console
- ./x86_64-native-linuxapp-gcc/app/testpmd -c f -n 4 --vdev="net_xenvirt0,mac=00:00:00:00:00:22" -- -i --eth-peer=0,00:00:00:00:00:33
+ ./x86_64-native-linuxapp-gcc/app/testpmd -l 0-3 -n 4 --vdev="net_xenvirt0,mac=00:00:00:00:00:22" -- -i --eth-peer=0,00:00:00:00:00:33
Configure a packet stream in the packet generator, and set the destination MAC address to 00:00:00:00:00:11 and VLAN to 1000.
The packets received in Virtio in guest VM1 will be forwarded to Virtio in guest VM2 and