xref: /dpdk/doc/guides/sample_app_ug/l3_forward.rst (revision 99f9d799ce21ab22e922ffec8aad51d56e24d04d)
1..  SPDX-License-Identifier: BSD-3-Clause
2    Copyright(c) 2010-2014 Intel Corporation.
3
4L3 Forwarding Sample Application
5================================
6
7The L3 Forwarding application is a simple example of packet processing using
8DPDK to demonstrate usage of poll and event mode packet I/O mechanism.
9The application performs L3 forwarding.
10
11Overview
12--------
13
14The application demonstrates the use of the hash, LPM and FIB libraries in DPDK
15to implement packet forwarding using poll or event mode PMDs for packet I/O.
16The initialization and run-time paths are very similar to those of the
17:doc:`l2_forward_real_virtual` and :doc:`l2_forward_event`.
18The main difference from the L2 Forwarding sample application is that optionally
19packet can be Rx/Tx from/to eventdev instead of port directly and forwarding
20decision is made based on information read from the input packet.
21
22Eventdev can optionally use S/W or H/W (if supported by platform) scheduler
23implementation for packet I/O based on run time parameters.
24
25The lookup method is hash-based, LPM-based or FIB-based
26and is selected at run time.
27When the selected lookup method is hash-based,
28a hash object is used to emulate the flow classification stage.
29The hash object is used in correlation with a flow table to map each input packet to its flow at runtime.
30
31The hash lookup key is represented by a DiffServ 5-tuple composed of the following fields read from the input packet:
32Source IP Address, Destination IP Address, Protocol, Source Port and Destination Port.
33The ID of the output interface for the input packet is read from the identified flow table entry.
34The set of flows used by the application is statically configured and loaded into the hash at initialization time.
35When the selected lookup method is LPM or FIB based,
36an LPM or FIB object is used to emulate the forwarding stage for IPv4 packets.
37The LPM or FIB object is used as the routing table
38to identify the next hop for each input packet at runtime.
39
40The LPM and FIB lookup keys are represented by the destination IP address field
41read from the input packet.
42The ID of the output interface for the input packet is the next hop
43returned by the LPM or FIB lookup.
44The set of LPM and FIB rules used by the application is statically configured
45and loaded into the LPM or FIB object at initialization time.
46
47In the sample application, hash-based and FIB-based forwarding supports
48both IPv4 and IPv6.
49LPM-based forwarding supports IPv4 only.
50
51Compiling the Application
52-------------------------
53
54To compile the sample application see :doc:`compiling`.
55
56The application is located in the ``l3fwd`` sub-directory.
57
58Running the Application
59-----------------------
60
61The application has a number of command line options::
62
63    ./dpdk-l3fwd [EAL options] -- -p PORTMASK
64                             [-P]
65                             [--lookup LOOKUP_METHOD]
66                             --config(port,queue,lcore)[,(port,queue,lcore)]
67                             [--eth-dest=X,MM:MM:MM:MM:MM:MM]
68                             [--enable-jumbo [--max-pkt-len PKTLEN]]
69                             [--no-numa]
70                             [--hash-entry-num]
71                             [--ipv6]
72                             [--parse-ptype]
73                             [--per-port-pool]
74                             [--mode]
75                             [--eventq-sched]
76                             [--event-eth-rxqs]
77                             [-E]
78                             [-L]
79
80Where,
81
82* ``-p PORTMASK:`` Hexadecimal bitmask of ports to configure
83
84* ``-P:`` Optional, sets all ports to promiscuous mode so that packets are accepted regardless of the packet's Ethernet MAC destination address.
85  Without this option, only packets with the Ethernet MAC destination address set to the Ethernet address of the port are accepted.
86
87* ``--lookup:`` Optional, select the lookup method.
88  Accepted options:
89  ``em`` (Exact Match),
90  ``lpm`` (Longest Prefix Match),
91  ``fib`` (Forwarding Information Base).
92  Default is ``lpm``.
93
94* ``--config (port,queue,lcore)[,(port,queue,lcore)]:`` Determines which queues from which ports are mapped to which cores.
95
96* ``--eth-dest=X,MM:MM:MM:MM:MM:MM:`` Optional, ethernet destination for port X.
97
98* ``--enable-jumbo:`` Optional, enables jumbo frames.
99
100* ``--max-pkt-len:`` Optional, under the premise of enabling jumbo, maximum packet length in decimal (64-9600).
101
102* ``--no-numa:`` Optional, disables numa awareness.
103
104* ``--hash-entry-num:`` Optional, specifies the hash entry number in hexadecimal to be setup.
105
106* ``--ipv6:`` Optional, set if running ipv6 packets.
107
108* ``--parse-ptype:`` Optional, set to use software to analyze packet type. Without this option, hardware will check the packet type.
109
110* ``--per-port-pool:`` Optional, set to use independent buffer pools per port. Without this option, single buffer pool is used for all ports.
111
112* ``--mode:`` Optional, Packet transfer mode for I/O, poll or eventdev.
113
114* ``--eventq-sched:`` Optional, Event queue synchronization method, Ordered, Atomic or Parallel. Only valid if --mode=eventdev.
115
116* ``--event-eth-rxqs:`` Optional, Number of ethernet RX queues per device. Only valid if --mode=eventdev.
117
118* ``-E:`` Optional, enable exact match,
119  legacy flag, please use ``--lookup=em`` instead.
120
121* ``-L:`` Optional, enable longest prefix match,
122  legacy flag, please use ``--lookup=lpm`` instead.
123
124
125For example, consider a dual processor socket platform with 8 physical cores, where cores 0-7 and 16-23 appear on socket 0,
126while cores 8-15 and 24-31 appear on socket 1.
127
128To enable L3 forwarding between two ports, assuming that both ports are in the same socket, using two cores, cores 1 and 2,
129(which are in the same socket too), use the following command:
130
131.. code-block:: console
132
133    ./<build_dir>/examples/dpdk-l3fwd -l 1,2 -n 4 -- -p 0x3 --config="(0,0,1),(1,0,2)"
134
135In this command:
136
137*   The -l option enables cores 1, 2
138
139*   The -p option enables ports 0 and 1
140
141*   The --config option enables one queue on each port and maps each (port,queue) pair to a specific core.
142    The following table shows the mapping in this example:
143
144+----------+-----------+-----------+-------------------------------------+
145| **Port** | **Queue** | **lcore** | **Description**                     |
146|          |           |           |                                     |
147+----------+-----------+-----------+-------------------------------------+
148| 0        | 0         | 1         | Map queue 0 from port 0 to lcore 1. |
149|          |           |           |                                     |
150+----------+-----------+-----------+-------------------------------------+
151| 1        | 0         | 2         | Map queue 0 from port 1 to lcore 2. |
152|          |           |           |                                     |
153+----------+-----------+-----------+-------------------------------------+
154
155To use eventdev mode with sync method **ordered** on above mentioned environment,
156Following is the sample command:
157
158.. code-block:: console
159
160    ./<build_dir>/examples/dpdk-l3fwd -l 0-3 -n 4 -a <event device> -- -p 0x3 --eventq-sched=ordered
161
162or
163
164.. code-block:: console
165
166    ./<build_dir>/examples/dpdk-l3fwd -l 0-3 -n 4 -a <event device> \
167		-- -p 0x03 --mode=eventdev --eventq-sched=ordered
168
169In this command:
170
171*   -a option allows the event device supported by platform.
172    The syntax used to indicate this device may vary based on platform.
173
174*   The --mode option defines PMD to be used for packet I/O.
175
176*   The --eventq-sched option enables synchronization menthod of event queue so that packets will be scheduled accordingly.
177
178If application uses S/W scheduler, it uses following DPDK services:
179
180*   Software scheduler
181*   Rx adapter service function
182*   Tx adapter service function
183
184Application needs service cores to run above mentioned services. Service cores
185must be provided as EAL parameters along with the --vdev=event_sw0 to enable S/W
186scheduler. Following is the sample command:
187
188.. code-block:: console
189
190    ./<build_dir>/examples/dpdk-l3fwd -l 0-7 -s 0xf0000 -n 4 --vdev event_sw0 -- -p 0x3 --mode=eventdev --eventq-sched=ordered
191
192In case of eventdev mode, *--config* option is not used for ethernet port
193configuration. Instead each ethernet port will be configured with mentioned
194setup:
195
196*   Single Rx/Tx queue
197
198*   Each Rx queue will be connected to event queue via Rx adapter.
199
200*   Each Tx queue will be connected via Tx adapter.
201
202Refer to the *DPDK Getting Started Guide* for general information on running applications and
203the Environment Abstraction Layer (EAL) options.
204
205.. _l3_fwd_explanation:
206
207Explanation
208-----------
209
210The following sections provide some explanation of the sample application code. As mentioned in the overview section,
211the initialization and run-time paths are very similar to those of the :doc:`l2_forward_real_virtual` and :doc:`l2_forward_event`.
212The following sections describe aspects that are specific to the L3 Forwarding sample application.
213
214Hash Initialization
215~~~~~~~~~~~~~~~~~~~
216
217The hash object is created and loaded with the pre-configured entries read from a global array,
218and then generate the expected 5-tuple as key to keep consistence with those of real flow
219for the convenience to execute hash performance test on 4M/8M/16M flows.
220
221.. note::
222
223    The Hash initialization will setup both ipv4 and ipv6 hash table,
224    and populate the either table depending on the value of variable ipv6.
225    To support the hash performance test with up to 8M single direction flows/16M bi-direction flows,
226    populate_ipv4_many_flow_into_table() function will populate the hash table with specified hash table entry number(default 4M).
227
228.. note::
229
230    Value of global variable ipv6 can be specified with --ipv6 in the command line.
231    Value of global variable hash_entry_number,
232    which is used to specify the total hash entry number for all used ports in hash performance test,
233    can be specified with --hash-entry-num VALUE in command line, being its default value 4.
234
235.. code-block:: c
236
237    #if (APP_LOOKUP_METHOD == APP_LOOKUP_EXACT_MATCH)
238
239        static void
240        setup_hash(int socketid)
241        {
242            // ...
243
244            if (hash_entry_number != HASH_ENTRY_NUMBER_DEFAULT) {
245                if (ipv6 == 0) {
246                    /* populate the ipv4 hash */
247                    populate_ipv4_many_flow_into_table(ipv4_l3fwd_lookup_struct[socketid], hash_entry_number);
248                } else {
249                    /* populate the ipv6 hash */
250                    populate_ipv6_many_flow_into_table( ipv6_l3fwd_lookup_struct[socketid], hash_entry_number);
251                }
252            } else
253                if (ipv6 == 0) {
254                    /* populate the ipv4 hash */
255                    populate_ipv4_few_flow_into_table(ipv4_l3fwd_lookup_struct[socketid]);
256                } else {
257                    /* populate the ipv6 hash */
258                    populate_ipv6_few_flow_into_table(ipv6_l3fwd_lookup_struct[socketid]);
259                }
260            }
261        }
262    #endif
263
264LPM Initialization
265~~~~~~~~~~~~~~~~~~
266
267The LPM object is created and loaded with the pre-configured entries read from a global array.
268
269.. code-block:: c
270
271    #if (APP_LOOKUP_METHOD == APP_LOOKUP_LPM)
272
273    static void
274    setup_lpm(int socketid)
275    {
276        unsigned i;
277        int ret;
278        char s[64];
279
280        /* create the LPM table */
281
282        snprintf(s, sizeof(s), "IPV4_L3FWD_LPM_%d", socketid);
283
284        ipv4_l3fwd_lookup_struct[socketid] = rte_lpm_create(s, socketid, IPV4_L3FWD_LPM_MAX_RULES, 0);
285
286        if (ipv4_l3fwd_lookup_struct[socketid] == NULL)
287            rte_exit(EXIT_FAILURE, "Unable to create the l3fwd LPM table"
288                " on socket %d\n", socketid);
289
290        /* populate the LPM table */
291
292        for (i = 0; i < IPV4_L3FWD_NUM_ROUTES; i++) {
293            /* skip unused ports */
294
295            if ((1 << ipv4_l3fwd_route_array[i].if_out & enabled_port_mask) == 0)
296                continue;
297
298            ret = rte_lpm_add(ipv4_l3fwd_lookup_struct[socketid], ipv4_l3fwd_route_array[i].ip,
299           	                    ipv4_l3fwd_route_array[i].depth, ipv4_l3fwd_route_array[i].if_out);
300
301            if (ret < 0) {
302                rte_exit(EXIT_FAILURE, "Unable to add entry %u to the "
303                        "l3fwd LPM table on socket %d\n", i, socketid);
304            }
305
306            printf("LPM: Adding route 0x%08x / %d (%d)\n",
307                (unsigned)ipv4_l3fwd_route_array[i].ip, ipv4_l3fwd_route_array[i].depth, ipv4_l3fwd_route_array[i].if_out);
308        }
309    }
310    #endif
311
312FIB Initialization
313~~~~~~~~~~~~~~~~~~
314
315The FIB object is created and loaded with the pre-configured entries
316read from a global array.
317The abridged code snippet below shows the FIB initialization for IPv4,
318the full setup function including the IPv6 setup can be seen in the app code.
319
320.. literalinclude:: ../../../examples/l3fwd/l3fwd_fib.c
321   :language: c
322   :start-after: Function to setup fib.
323   :end-before: Create the fib IPv6 table.
324
325Packet Forwarding for Hash-based Lookups
326~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
327
328For each input packet, the packet forwarding operation is done by the l3fwd_simple_forward()
329or simple_ipv4_fwd_4pkts() function for IPv4 packets or the simple_ipv6_fwd_4pkts() function for IPv6 packets.
330The l3fwd_simple_forward() function provides the basic functionality for both IPv4 and IPv6 packet forwarding
331for any number of burst packets received,
332and the packet forwarding decision (that is, the identification of the output interface for the packet)
333for hash-based lookups is done by the  get_ipv4_dst_port() or get_ipv6_dst_port() function.
334The get_ipv4_dst_port() function is shown below:
335
336.. code-block:: c
337
338    static inline uint8_t
339    get_ipv4_dst_port(void *ipv4_hdr, uint16_t portid, lookup_struct_t *ipv4_l3fwd_lookup_struct)
340    {
341        int ret = 0;
342        union ipv4_5tuple_host key;
343
344        ipv4_hdr = (uint8_t *)ipv4_hdr + offsetof(struct rte_ipv4_hdr, time_to_live);
345
346        m128i data = _mm_loadu_si128(( m128i*)(ipv4_hdr));
347
348        /* Get 5 tuple: dst port, src port, dst IP address, src IP address and protocol */
349
350        key.xmm = _mm_and_si128(data, mask0);
351
352        /* Find destination port */
353
354        ret = rte_hash_lookup(ipv4_l3fwd_lookup_struct, (const void *)&key);
355
356        return (uint8_t)((ret < 0)? portid : ipv4_l3fwd_out_if[ret]);
357    }
358
359The get_ipv6_dst_port() function is similar to the get_ipv4_dst_port() function.
360
361The simple_ipv4_fwd_4pkts() and simple_ipv6_fwd_4pkts() function are optimized for continuous 4 valid ipv4 and ipv6 packets,
362they leverage the multiple buffer optimization to boost the performance of forwarding packets with the exact match on hash table.
363The key code snippet of simple_ipv4_fwd_4pkts() is shown below:
364
365.. code-block:: c
366
367    static inline void
368    simple_ipv4_fwd_4pkts(struct rte_mbuf* m[4], uint16_t portid, struct lcore_conf *qconf)
369    {
370        // ...
371
372        data[0] = _mm_loadu_si128(( m128i*)(rte_pktmbuf_mtod(m[0], unsigned char *) + sizeof(struct rte_ether_hdr) + offsetof(struct rte_ipv4_hdr, time_to_live)));
373        data[1] = _mm_loadu_si128(( m128i*)(rte_pktmbuf_mtod(m[1], unsigned char *) + sizeof(struct rte_ether_hdr) + offsetof(struct rte_ipv4_hdr, time_to_live)));
374        data[2] = _mm_loadu_si128(( m128i*)(rte_pktmbuf_mtod(m[2], unsigned char *) + sizeof(struct rte_ether_hdr) + offsetof(struct rte_ipv4_hdr, time_to_live)));
375        data[3] = _mm_loadu_si128(( m128i*)(rte_pktmbuf_mtod(m[3], unsigned char *) + sizeof(struct rte_ether_hdr) + offsetof(struct rte_ipv4_hdr, time_to_live)));
376
377        key[0].xmm = _mm_and_si128(data[0], mask0);
378        key[1].xmm = _mm_and_si128(data[1], mask0);
379        key[2].xmm = _mm_and_si128(data[2], mask0);
380        key[3].xmm = _mm_and_si128(data[3], mask0);
381
382        const void *key_array[4] = {&key[0], &key[1], &key[2],&key[3]};
383
384        rte_hash_lookup_bulk(qconf->ipv4_lookup_struct, &key_array[0], 4, ret);
385
386        dst_port[0] = (ret[0] < 0)? portid:ipv4_l3fwd_out_if[ret[0]];
387        dst_port[1] = (ret[1] < 0)? portid:ipv4_l3fwd_out_if[ret[1]];
388        dst_port[2] = (ret[2] < 0)? portid:ipv4_l3fwd_out_if[ret[2]];
389        dst_port[3] = (ret[3] < 0)? portid:ipv4_l3fwd_out_if[ret[3]];
390
391        // ...
392    }
393
394The simple_ipv6_fwd_4pkts() function is similar to the simple_ipv4_fwd_4pkts() function.
395
396Known issue: IP packets with extensions or IP packets which are not TCP/UDP cannot work well at this mode.
397
398Packet Forwarding for LPM-based Lookups
399~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
400
401For each input packet, the packet forwarding operation is done by the l3fwd_simple_forward() function,
402but the packet forwarding decision (that is, the identification of the output interface for the packet)
403for LPM-based lookups is done by the get_ipv4_dst_port() function below:
404
405.. code-block:: c
406
407    static inline uint16_t
408    get_ipv4_dst_port(struct rte_ipv4_hdr *ipv4_hdr, uint16_t portid, lookup_struct_t *ipv4_l3fwd_lookup_struct)
409    {
410        uint8_t next_hop;
411
412        return ((rte_lpm_lookup(ipv4_l3fwd_lookup_struct, rte_be_to_cpu_32(ipv4_hdr->dst_addr), &next_hop) == 0)? next_hop : portid);
413    }
414
415Packet Forwarding for FIB-based Lookups
416~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
417
418The FIB library was designed to process multiple packets at once,
419it does not have separate functions for single and bulk lookups.
420``rte_fib_lookup_bulk`` is used for IPv4 lookups
421and ``rte_fib6_lookup_bulk`` for IPv6.
422Various examples of these functions being used
423can be found in the sample app code.
424
425Eventdev Driver Initialization
426~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
427Eventdev driver initialization is same as L2 forwarding eventdev application.
428Refer :doc:`l2_forward_event` for more details.
429