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