1 .. SPDX-License-Identifier: BSD-3-Clause
2 Copyright(c) 2010-2014 Intel Corporation.
4 L3 Forwarding Sample Application
5 ================================
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.
14 The application demonstrates the use of the hash, LPM and FIB libraries in 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.
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.
25 The lookup method is hash-based, LPM-based or FIB-based
26 and is selected at run time.
27 When the selected lookup method is hash-based,
28 a hash object is used to emulate the flow classification stage.
29 The hash object is used in correlation with a flow table to map each input packet to its flow at runtime.
31 The hash lookup key is represented by a DiffServ 5-tuple composed of the following fields read from the input packet:
32 Source IP Address, Destination IP Address, Protocol, Source Port and Destination Port.
33 The ID of the output interface for the input packet is read from the identified flow table entry.
34 The set of flows used by the application is statically configured and loaded into the hash at initialization time.
35 When the selected lookup method is LPM or FIB based,
36 an LPM or FIB object is used to emulate the forwarding stage for IPv4 packets.
37 The LPM or FIB object is used as the routing table
38 to identify the next hop for each input packet at runtime.
40 The LPM and FIB lookup keys are represented by the destination IP address field
41 read from the input packet.
42 The ID of the output interface for the input packet is the next hop
43 returned by the LPM or FIB lookup.
44 The set of LPM and FIB rules used by the application is statically configured
45 and loaded into the LPM or FIB object at initialization time.
47 In the sample application, hash-based and FIB-based forwarding supports
49 LPM-based forwarding supports IPv4 only.
51 Compiling the Application
52 -------------------------
54 To compile the sample application see :doc:`compiling`.
56 The application is located in the ``l3fwd`` sub-directory.
58 Running the Application
59 -----------------------
61 The application has a number of command line options::
63 ./dpdk-l3fwd [EAL options] -- -p PORTMASK
65 [--lookup LOOKUP_METHOD]
66 --config(port,queue,lcore)[,(port,queue,lcore)]
67 [--eth-dest=X,MM:MM:MM:MM:MM:MM]
68 [--max-pkt-len PKTLEN]
77 [--event-vector [--event-vector-size SIZE] [--event-vector-tmo NS]]
83 * ``-p PORTMASK:`` Hexadecimal bitmask of ports to configure
85 * ``-P:`` Optional, sets all ports to promiscuous mode so that packets are accepted regardless of the packet's Ethernet MAC destination address.
86 Without this option, only packets with the Ethernet MAC destination address set to the Ethernet address of the port are accepted.
88 * ``--lookup:`` Optional, select the lookup method.
91 ``lpm`` (Longest Prefix Match),
92 ``fib`` (Forwarding Information Base).
95 * ``--config (port,queue,lcore)[,(port,queue,lcore)]:`` Determines which queues from which ports are mapped to which cores.
97 * ``--eth-dest=X,MM:MM:MM:MM:MM:MM:`` Optional, ethernet destination for port X.
99 * ``--max-pkt-len:`` Optional, maximum packet length in decimal (64-9600).
101 * ``--no-numa:`` Optional, disables numa awareness.
103 * ``--hash-entry-num:`` Optional, specifies the hash entry number in hexadecimal to be setup.
105 * ``--ipv6:`` Optional, set if running ipv6 packets.
107 * ``--parse-ptype:`` Optional, set to use software to analyze packet type. Without this option, hardware will check the packet type.
109 * ``--per-port-pool:`` Optional, set to use independent buffer pools per port. Without this option, single buffer pool is used for all ports.
111 * ``--mode:`` Optional, Packet transfer mode for I/O, poll or eventdev.
113 * ``--eventq-sched:`` Optional, Event queue synchronization method, Ordered, Atomic or Parallel. Only valid if --mode=eventdev.
115 * ``--event-eth-rxqs:`` Optional, Number of ethernet RX queues per device. Only valid if --mode=eventdev.
117 * ``--event-vector:`` Optional, Enable event vectorization. Only valid if --mode=eventdev.
119 * ``--event-vector-size:`` Optional, Max vector size if event vectorization is enabled.
121 * ``--event-vector-tmo:`` Optional, Max timeout to form vector in nanoseconds if event vectorization is enabled.
123 * ``-E:`` Optional, enable exact match,
124 legacy flag, please use ``--lookup=em`` instead.
126 * ``-L:`` Optional, enable longest prefix match,
127 legacy flag, please use ``--lookup=lpm`` instead.
130 For example, consider a dual processor socket platform with 8 physical cores, where cores 0-7 and 16-23 appear on socket 0,
131 while cores 8-15 and 24-31 appear on socket 1.
133 To enable L3 forwarding between two ports, assuming that both ports are in the same socket, using two cores, cores 1 and 2,
134 (which are in the same socket too), use the following command:
136 .. code-block:: console
138 ./<build_dir>/examples/dpdk-l3fwd -l 1,2 -n 4 -- -p 0x3 --config="(0,0,1),(1,0,2)"
142 * The -l option enables cores 1, 2
144 * The -p option enables ports 0 and 1
146 * The --config option enables one queue on each port and maps each (port,queue) pair to a specific core.
147 The following table shows the mapping in this example:
149 +----------+-----------+-----------+-------------------------------------+
150 | **Port** | **Queue** | **lcore** | **Description** |
152 +----------+-----------+-----------+-------------------------------------+
153 | 0 | 0 | 1 | Map queue 0 from port 0 to lcore 1. |
155 +----------+-----------+-----------+-------------------------------------+
156 | 1 | 0 | 2 | Map queue 0 from port 1 to lcore 2. |
158 +----------+-----------+-----------+-------------------------------------+
160 To use eventdev mode with sync method **ordered** on above mentioned environment,
161 Following is the sample command:
163 .. code-block:: console
165 ./<build_dir>/examples/dpdk-l3fwd -l 0-3 -n 4 -a <event device> -- -p 0x3 --eventq-sched=ordered
169 .. code-block:: console
171 ./<build_dir>/examples/dpdk-l3fwd -l 0-3 -n 4 -a <event device> \
172 -- -p 0x03 --mode=eventdev --eventq-sched=ordered
176 * -a option allows the event device supported by platform.
177 The syntax used to indicate this device may vary based on platform.
179 * The --mode option defines PMD to be used for packet I/O.
181 * The --eventq-sched option enables synchronization menthod of event queue so that packets will be scheduled accordingly.
183 If application uses S/W scheduler, it uses following DPDK services:
186 * Rx adapter service function
187 * Tx adapter service function
189 Application needs service cores to run above mentioned services. Service cores
190 must be provided as EAL parameters along with the --vdev=event_sw0 to enable S/W
191 scheduler. Following is the sample command:
193 .. code-block:: console
195 ./<build_dir>/examples/dpdk-l3fwd -l 0-7 -s 0xf0000 -n 4 --vdev event_sw0 -- -p 0x3 --mode=eventdev --eventq-sched=ordered
197 In case of eventdev mode, *--config* option is not used for ethernet port
198 configuration. Instead each ethernet port will be configured with mentioned
203 * Each Rx queue will be connected to event queue via Rx adapter.
205 * Each Tx queue will be connected via Tx adapter.
207 Refer to the *DPDK Getting Started Guide* for general information on running applications and
208 the Environment Abstraction Layer (EAL) options.
210 .. _l3_fwd_explanation:
215 The following sections provide some explanation of the sample application code. As mentioned in the overview section,
216 the initialization and run-time paths are very similar to those of the :doc:`l2_forward_real_virtual` and :doc:`l2_forward_event`.
217 The following sections describe aspects that are specific to the L3 Forwarding sample application.
222 The hash object is created and loaded with the pre-configured entries read from a global array,
223 and then generate the expected 5-tuple as key to keep consistence with those of real flow
224 for the convenience to execute hash performance test on 4M/8M/16M flows.
228 The Hash initialization will setup both ipv4 and ipv6 hash table,
229 and populate the either table depending on the value of variable ipv6.
230 To support the hash performance test with up to 8M single direction flows/16M bi-direction flows,
231 populate_ipv4_many_flow_into_table() function will populate the hash table with specified hash table entry number(default 4M).
235 Value of global variable ipv6 can be specified with --ipv6 in the command line.
236 Value of global variable hash_entry_number,
237 which is used to specify the total hash entry number for all used ports in hash performance test,
238 can be specified with --hash-entry-num VALUE in command line, being its default value 4.
242 #if (APP_LOOKUP_METHOD == APP_LOOKUP_EXACT_MATCH)
245 setup_hash(int socketid)
249 if (hash_entry_number != HASH_ENTRY_NUMBER_DEFAULT) {
251 /* populate the ipv4 hash */
252 populate_ipv4_many_flow_into_table(ipv4_l3fwd_lookup_struct[socketid], hash_entry_number);
254 /* populate the ipv6 hash */
255 populate_ipv6_many_flow_into_table( ipv6_l3fwd_lookup_struct[socketid], hash_entry_number);
259 /* populate the ipv4 hash */
260 populate_ipv4_few_flow_into_table(ipv4_l3fwd_lookup_struct[socketid]);
262 /* populate the ipv6 hash */
263 populate_ipv6_few_flow_into_table(ipv6_l3fwd_lookup_struct[socketid]);
272 The LPM object is created and loaded with the pre-configured entries read from a global array.
274 .. literalinclude:: ../../../examples/l3fwd/l3fwd_em.c
276 :start-after: Initialize exact match (hash) parameters. 8<
277 :end-before: >8 End of initialization of hash parameters.
282 The FIB object is created and loaded with the pre-configured entries
283 read from a global array.
284 The abridged code snippet below shows the FIB initialization for IPv4,
285 the full setup function including the IPv6 setup can be seen in the app code.
287 .. literalinclude:: ../../../examples/l3fwd/l3fwd_fib.c
289 :start-after: Function to setup fib. 8<
290 :end-before: >8 End of setup fib.
292 Packet Forwarding for Hash-based Lookups
293 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
295 For each input packet, the packet forwarding operation is done by the l3fwd_simple_forward()
296 or simple_ipv4_fwd_4pkts() function for IPv4 packets or the simple_ipv6_fwd_4pkts() function for IPv6 packets.
297 The l3fwd_simple_forward() function provides the basic functionality for both IPv4 and IPv6 packet forwarding
298 for any number of burst packets received,
299 and the packet forwarding decision (that is, the identification of the output interface for the packet)
300 for hash-based lookups is done by the get_ipv4_dst_port() or get_ipv6_dst_port() function.
301 The get_ipv4_dst_port() function is shown below:
303 .. literalinclude:: ../../../examples/l3fwd/l3fwd_em.c
305 :start-after: Performing hash-based lookups. 8<
306 :end-before: >8 End of performing hash-based lookups.
308 The get_ipv6_dst_port() function is similar to the get_ipv4_dst_port() function.
310 The simple_ipv4_fwd_4pkts() and simple_ipv6_fwd_4pkts() function are optimized for continuous 4 valid ipv4 and ipv6 packets,
311 they leverage the multiple buffer optimization to boost the performance of forwarding packets with the exact match on hash table.
312 The key code snippet of simple_ipv4_fwd_4pkts() is shown below:
317 simple_ipv4_fwd_4pkts(struct rte_mbuf* m[4], uint16_t portid, struct lcore_conf *qconf)
321 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)));
322 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)));
323 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)));
324 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)));
326 key[0].xmm = _mm_and_si128(data[0], mask0);
327 key[1].xmm = _mm_and_si128(data[1], mask0);
328 key[2].xmm = _mm_and_si128(data[2], mask0);
329 key[3].xmm = _mm_and_si128(data[3], mask0);
331 const void *key_array[4] = {&key[0], &key[1], &key[2],&key[3]};
333 rte_hash_lookup_bulk(qconf->ipv4_lookup_struct, &key_array[0], 4, ret);
335 dst_port[0] = (ret[0] < 0)? portid:ipv4_l3fwd_out_if[ret[0]];
336 dst_port[1] = (ret[1] < 0)? portid:ipv4_l3fwd_out_if[ret[1]];
337 dst_port[2] = (ret[2] < 0)? portid:ipv4_l3fwd_out_if[ret[2]];
338 dst_port[3] = (ret[3] < 0)? portid:ipv4_l3fwd_out_if[ret[3]];
343 The simple_ipv6_fwd_4pkts() function is similar to the simple_ipv4_fwd_4pkts() function.
345 Known issue: IP packets with extensions or IP packets which are not TCP/UDP cannot work well at this mode.
347 Packet Forwarding for LPM-based Lookups
348 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
350 For each input packet, the packet forwarding operation is done by the l3fwd_simple_forward() function,
351 but the packet forwarding decision (that is, the identification of the output interface for the packet)
352 for LPM-based lookups is done by the get_ipv4_dst_port() function below:
354 .. literalinclude:: ../../../examples/l3fwd/l3fwd_lpm.c
356 :start-after: Performing LPM-based lookups. 8<
357 :end-before: >8 End of performing LPM-based lookups.
359 Packet Forwarding for FIB-based Lookups
360 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
362 The FIB library was designed to process multiple packets at once,
363 it does not have separate functions for single and bulk lookups.
364 ``rte_fib_lookup_bulk`` is used for IPv4 lookups
365 and ``rte_fib6_lookup_bulk`` for IPv6.
366 Various examples of these functions being used
367 can be found in the sample app code.
369 Eventdev Driver Initialization
370 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
371 Eventdev driver initialization is same as L2 forwarding eventdev application.
372 Refer :doc:`l2_forward_event` for more details.