xref: /dpdk/doc/guides/sample_app_ug/l2_forward_real_virtual.rst (revision 8750576fb2a9a067ffbcce4bab6481f3bfa47097)
1..  SPDX-License-Identifier: BSD-3-Clause
2    Copyright(c) 2010-2014 Intel Corporation.
3
4L2 Forwarding Sample Application (in Real and Virtualized Environments)
5=======================================================================
6
7The L2 Forwarding sample application is an example of packet processing
8using the Data Plane Development Kit (DPDK).
9It also takes advantage of Single Root I/O Virtualization (SR-IOV) features
10in a virtualized environment.
11
12.. note::
13
14    Please note that previously a separate L2 Forwarding in Virtualized Environments sample application was used,
15    however, in later DPDK versions these sample applications have been merged.
16
17Overview
18--------
19
20The L2 Forwarding sample application, which can operate in real and virtualized environments,
21performs L2 forwarding for each packet that is received on an RX_PORT.
22The destination port is the adjacent port from the enabled portmask
23if: the first four ports are enabled (portmask 0xf),
24ports 1 and 2 forward into each other, and ports 3 and 4 forward into each other.
25Also, if MAC address updating is enabled, the MAC addresses are affected as follows:
26
27*   The source MAC address is replaced by the TX_PORT MAC address
28
29*   The destination MAC address is replaced by  02:00:00:00:00:TX_PORT_ID
30
31This application can be used to benchmark performance using a traffic-generator, as shown in the :numref:`figure_l2_fwd_benchmark_setup`,
32or in a virtualized environment as shown in :numref:`figure_l2_fwd_virtenv_benchmark_setup`.
33
34.. _figure_l2_fwd_benchmark_setup:
35
36.. figure:: img/l2_fwd_benchmark_setup.*
37
38   Performance Benchmark Setup (Basic Environment)
39
40.. _figure_l2_fwd_virtenv_benchmark_setup:
41
42.. figure:: img/l2_fwd_virtenv_benchmark_setup.*
43
44   Performance Benchmark Setup (Virtualized Environment)
45
46This application may be used for basic VM to VM communication as shown in :numref:`figure_l2_fwd_vm2vm`,
47when MAC addresses updating is disabled.
48
49.. _figure_l2_fwd_vm2vm:
50
51.. figure:: img/l2_fwd_vm2vm.*
52
53   Virtual Machine to Virtual Machine communication.
54
55The L2 Forwarding application can also be used as a starting point for developing a new application based on the DPDK.
56
57.. _l2_fwd_vf_setup:
58
59Virtual Function Setup Instructions
60~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
61
62This application can use the virtual function available in the system and
63therefore can be used in a virtual machine without passing through
64the whole Network Device into a guest machine in a virtualized scenario.
65The virtual functions can be enabled in the host machine or the hypervisor with the respective physical function driver.
66
67For example, in a Linux* host machine, it is possible to enable a virtual function using the following command:
68
69.. code-block:: console
70
71    modprobe ixgbe max_vfs=2,2
72
73This command enables two Virtual Functions on each of Physical Function of the NIC,
74with two physical ports in the PCI configuration space.
75It is important to note that enabled Virtual Function 0 and 2 would belong to Physical Function 0
76and Virtual Function 1 and 3 would belong to Physical Function 1,
77in this case, enabling a total of four Virtual Functions.
78
79Compiling the Application
80-------------------------
81
82To compile the sample application, see :doc:`compiling`.
83
84The application is located in the ``l2fwd`` sub-directory.
85
86Running the Application
87-----------------------
88
89The application requires a number of command line options:
90
91.. code-block:: console
92
93    ./<build_dir>/examples/dpdk-l2fwd [EAL options] -- -p PORTMASK
94                                   [-P]
95                                   [-q NQ]
96                                   --[no-]mac-updating
97                                   [--portmap="(port, port)[,(port, port)]"]
98
99where,
100
101*   p PORTMASK: A hexadecimal bitmask of the ports to configure
102
103*   P: Optional, set all ports to promiscuous mode
104    so that packets are accepted regardless of the MAC destination address.
105    Without this option, only packets with the MAC destination address
106    set to the Ethernet address of the port are accepted.
107
108*   q NQ: Maximum number of queues per lcore (default is 1)
109
110*   --[no-]mac-updating: Enable or disable MAC addresses updating (enabled by default)
111
112*   --portmap="(port,port)[,(port,port)]": Determines forwarding ports mapping.
113
114To run the application in linux environment with 4 lcores, 16 ports and 8 RX queues per lcore and MAC address
115updating enabled, issue the command:
116
117.. code-block:: console
118
119    $ ./<build_dir>/examples/dpdk-l2fwd -l 0-3 -n 4 -- -q 8 -p ffff
120
121To run the application in linux environment with 4 lcores, 4 ports, 8 RX queues
122per lcore, to forward RX traffic of ports 0 & 1 on ports 2 & 3 respectively and
123vice versa, issue the command:
124
125.. code-block:: console
126
127    $ ./<build_dir>/examples/dpdk-l2fwd -l 0-3 -n 4 -- -q 8 -p f --portmap="(0,2)(1,3)"
128
129Refer to the *DPDK Getting Started Guide* for general information on running applications
130and the Environment Abstraction Layer (EAL) options.
131
132Explanation
133-----------
134
135The following sections provide explanation of the code.
136
137.. _l2_fwd_app_cmd_arguments:
138
139Command Line Arguments
140~~~~~~~~~~~~~~~~~~~~~~
141
142The L2 Forwarding sample application takes specific parameters
143and Environment Abstraction Layer (EAL) arguments.
144The preferred way to parse parameters is to use the ``getopt()`` function
145since it is part of a well-defined and portable library.
146
147The parsing of arguments is done in the ``l2fwd_parse_args()`` function.
148This method of argument parsing is not described here.
149Refer to the *glibc getopt(3)* main page for details.
150
151EAL arguments are parsed first, then application-specific arguments.
152This is done at the beginning of the main() function:
153
154.. literalinclude:: ../../../examples/l2fwd/main.c
155    :language: c
156    :start-after: Init EAL. 8<
157    :end-before: >8 End of init EAL.
158    :dedent: 1
159
160.. _l2_fwd_app_mbuf_init:
161
162Mbuf Pool Initialization
163~~~~~~~~~~~~~~~~~~~~~~~~
164
165Once the arguments are parsed, the mbuf pool is created.
166The mbuf pool contains a set of mbuf objects that will be used by the driver
167and the application to store network packet data:
168
169.. literalinclude:: ../../../examples/l2fwd/main.c
170    :language: c
171    :start-after: Create the mbuf pool. 8<
172    :end-before: >8 End of create the mbuf pool.
173    :dedent: 1
174
175The rte_mempool is a generic structure used to handle pools of objects.
176In this case, it is necessary to create a pool that will be used by the driver.
177The number of allocated pkt mbufs is ``NB_MBUF``,
178with a data room size of ``RTE_MBUF_DEFAULT_BUF_SIZE`` each.
179A per-lcore cache of 32 mbufs is kept.
180The memory is allocated in NUMA socket 0,
181but it is possible to extend this code to allocate one mbuf pool per socket.
182
183The ``rte_pktmbuf_pool_create()`` function uses the default mbuf pool
184and mbuf initializers, respectively ``rte_pktmbuf_pool_init()`` and ``rte_pktmbuf_init()``.
185An advanced application may want to use the mempool API to create the
186mbuf pool with more control.
187
188.. _l2_fwd_app_dvr_init:
189
190Driver Initialization
191~~~~~~~~~~~~~~~~~~~~~
192
193The main part of the code in the ``main()`` function relates to the initialization of the driver.
194To fully understand this code, it is recommended to study the chapters related to the Poll Mode Driver
195in the *DPDK Programmer's Guide* - Rel 1.4 EAR and the *DPDK API Reference*.
196
197.. literalinclude:: ../../../examples/l2fwd/main.c
198    :language: c
199    :start-after: Initialization of the driver. 8<
200    :end-before: >8 End of initialization of the driver.
201    :dedent: 1
202
203The next step is to configure the RX and TX queues.
204For each port, there is only one RX queue (only one lcore is able to poll a given port).
205The number of TX queues depends on the number of available lcores.
206The ``rte_eth_dev_configure()`` function is used to configure the number of queues for a port:
207
208.. literalinclude:: ../../../examples/l2fwd/main.c
209    :language: c
210    :start-after: Configure the number of queues for a port.
211    :end-before: >8 End of configuration of the number of queues for a port.
212    :dedent: 2
213
214.. _l2_fwd_app_rx_init:
215
216RX Queue Initialization
217~~~~~~~~~~~~~~~~~~~~~~~
218
219The application uses one lcore to poll one or several ports depending on the ``-q`` option,
220which specifies the number of queues per lcore.
221
222For example, if the user specifies ``-q 4``,
223the application is able to poll four ports with one lcore.
224If there are 16 ports on the target (and if the portmask argument is ``-p ffff``),
225the application will need four lcores to poll all the ports.
226
227.. literalinclude:: ../../../examples/l2fwd/main.c
228    :language: c
229    :start-after: RX queue setup. 8<
230    :end-before: >8 End of RX queue setup.
231    :dedent: 2
232
233The list of queues that must be polled for a given lcore is stored in a private structure called struct lcore_queue_conf.
234
235.. literalinclude:: ../../../examples/l2fwd/main.c
236    :language: c
237    :start-after: List of queues to be polled for a given lcore. 8<
238    :end-before: >8 End of list of queues to be polled for a given lcore.
239
240The values ``n_rx_port`` and ``rx_port_list[]`` are used in the main packet processing loop
241(see :ref:`l2_fwd_app_rx_tx_packets`).
242
243.. _l2_fwd_app_tx_init:
244
245TX Queue Initialization
246~~~~~~~~~~~~~~~~~~~~~~~
247
248Each lcore should be able to transmit on any port.
249For each port, a single TX queue is initialized.
250
251.. literalinclude:: ../../../examples/l2fwd/main.c
252    :language: c
253    :start-after: Init one TX queue on each port. 8<
254    :end-before: >8 End of init one TX queue on each port.
255    :dedent: 2
256
257.. _l2_fwd_app_rx_tx_packets:
258
259Receive, Process and Transmit Packets
260~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
261
262In the ``l2fwd_main_loop()`` function,
263the main task is to read ingress packets from the RX queues.
264This is done using the following code:
265
266.. literalinclude:: ../../../examples/l2fwd/main.c
267    :language: c
268    :start-after: Read packet from RX queues. 8<
269    :end-before: >8 End of read packet from RX queues.
270    :dedent: 2
271
272Packets are read in a burst of size ``MAX_PKT_BURST``.
273The ``rte_eth_rx_burst()`` function writes the mbuf pointers
274in a local table and returns the number of available mbufs in the table.
275
276Then, each mbuf in the table is processed by the ``l2fwd_simple_forward()`` function.
277The processing is very simple: process the TX port from the RX port,
278then replace the source and destination MAC addresses if MAC address updating is enabled.
279
280.. note::
281
282    In the following code, one line for getting the output port requires some explanation.
283
284During the initialization process, a static array of destination ports (``l2fwd_dst_ports[]``)
285is filled such that for each source port,
286a destination port is assigned that is either the next or previous enabled port from the portmask.
287Naturally, the number of ports in the portmask must be even.
288Otherwise, the application exits.
289
290.. literalinclude:: ../../../examples/l2fwd/main.c
291    :language: c
292    :start-after: Simple forward. 8<
293    :end-before: >8 End of simple forward.
294
295
296At this point, the packet is sent using the ``l2fwd_send_packet(m, dst_port)`` function.
297For this test application, the processing is exactly the same for all packets arriving on the same RX port.
298Therefore, it would have been possible to call the ``l2fwd_send_burst()`` function
299directly from the main loop
300to send all the received packets on the same TX port,
301using the burst-oriented send function, which is more efficient.
302
303However, in real-life applications (such as L3 routing),
304packet N is not necessarily forwarded on the same port as packet N-1.
305The application is implemented to illustrate this
306so the same approach can be reused in a more complex application.
307
308The ``l2fwd_send_packet()`` function stores the packet in a per-lcore and per-txport table.
309If the table is full, the whole packets table is transmitted
310using the ``l2fwd_send_burst()`` function:
311
312.. literalinclude:: ../../../examples/l2fwd-crypto/main.c
313    :language: c
314    :start-after: Enqueue packets for TX and prepare them to be sent. 8<
315    :end-before: >8 End of Enqueuing packets for TX.
316
317To ensure that no packets remain in the tables, each lcore does a draining of TX queue in its main loop.
318This technique introduces some latency when there are not many packets to send.
319However it improves performance:
320
321.. literalinclude:: ../../../examples/l2fwd/main.c
322    :language: c
323    :start-after: Drains TX queue in its main loop. 8<
324    :end-before: >8 End of draining TX queue.
325    :dedent: 2
326