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. 50During the initialization phase route rules for IPv4 and IPv6 are read from rule files. 51 52Compiling the Application 53------------------------- 54 55To compile the sample application see :doc:`compiling`. 56 57The application is located in the ``l3fwd`` sub-directory. 58 59Running the Application 60----------------------- 61 62The application has a number of command line options:: 63 64 ./dpdk-l3fwd [EAL options] -- -p PORTMASK 65 --rule_ipv4=FILE 66 --rule_ipv6=FILE 67 [-P] 68 [--lookup LOOKUP_METHOD] 69 --config(port,queue,lcore)[,(port,queue,lcore)] 70 [--eth-dest=X,MM:MM:MM:MM:MM:MM] 71 [--max-pkt-len PKTLEN] 72 [--no-numa] 73 [--hash-entry-num] 74 [--ipv6] 75 [--parse-ptype] 76 [--per-port-pool] 77 [--mode] 78 [--eventq-sched] 79 [--event-eth-rxqs] 80 [--event-vector [--event-vector-size SIZE] [--event-vector-tmo NS]] 81 [-E] 82 [-L] 83 84Where, 85 86* ``-p PORTMASK:`` Hexadecimal bitmask of ports to configure 87 88* ``--rule_ipv4=FILE:`` specify the ipv4 rules entries file. 89 Each rule occupies one line. 90 91* ``--rule_ipv6=FILE:`` specify the ipv6 rules entries file. 92 93* ``-P:`` Optional, sets all ports to promiscuous mode so that packets are accepted regardless of the packet's Ethernet MAC destination address. 94 Without this option, only packets with the Ethernet MAC destination address set to the Ethernet address of the port are accepted. 95 96* ``--lookup:`` Optional, select the lookup method. 97 Accepted options: 98 ``em`` (Exact Match), 99 ``lpm`` (Longest Prefix Match), 100 ``fib`` (Forwarding Information Base). 101 Default is ``lpm``. 102 103* ``--config (port,queue,lcore)[,(port,queue,lcore)]:`` Determines which queues from which ports are mapped to which cores. 104 105* ``--eth-dest=X,MM:MM:MM:MM:MM:MM:`` Optional, ethernet destination for port X. 106 107* ``--max-pkt-len:`` Optional, maximum packet length in decimal (64-9600). 108 109* ``--no-numa:`` Optional, disables numa awareness. 110 111* ``--hash-entry-num:`` Optional, specifies the hash entry number in hexadecimal to be setup. 112 113* ``--ipv6:`` Optional, set if running ipv6 packets. 114 115* ``--parse-ptype:`` Optional, set to use software to analyze packet type. Without this option, hardware will check the packet type. 116 117* ``--per-port-pool:`` Optional, set to use independent buffer pools per port. Without this option, single buffer pool is used for all ports. 118 119* ``--mode:`` Optional, Packet transfer mode for I/O, poll or eventdev. 120 121* ``--eventq-sched:`` Optional, Event queue synchronization method, Ordered, Atomic or Parallel. Only valid if --mode=eventdev. 122 123* ``--event-eth-rxqs:`` Optional, Number of ethernet RX queues per device. Only valid if --mode=eventdev. 124 125* ``--event-vector:`` Optional, Enable event vectorization. Only valid if --mode=eventdev. 126 127* ``--event-vector-size:`` Optional, Max vector size if event vectorization is enabled. 128 129* ``--event-vector-tmo:`` Optional, Max timeout to form vector in nanoseconds if event vectorization is enabled. 130 131* ``-E:`` Optional, enable exact match, 132 legacy flag, please use ``--lookup=em`` instead. 133 134* ``-L:`` Optional, enable longest prefix match, 135 legacy flag, please use ``--lookup=lpm`` instead. 136 137 138For example, consider a dual processor socket platform with 8 physical cores, where cores 0-7 and 16-23 appear on socket 0, 139while cores 8-15 and 24-31 appear on socket 1. 140 141To enable L3 forwarding between two ports, assuming that both ports are in the same socket, using two cores, cores 1 and 2, 142(which are in the same socket too), use the following command: 143 144.. code-block:: console 145 146 ./<build_dir>/examples/dpdk-l3fwd -l 1,2 -n 4 -- -p 0x3 --config="(0,0,1),(1,0,2)" --rule_ipv4="rule_ipv4.cfg" --rule_ipv6="rule_ipv6.cfg" 147 148In this command: 149 150* The -l option enables cores 1, 2 151 152* The -p option enables ports 0 and 1 153 154* The --config option enables one queue on each port and maps each (port,queue) pair to a specific core. 155 The following table shows the mapping in this example: 156 157+----------+-----------+-----------+-------------------------------------+ 158| **Port** | **Queue** | **lcore** | **Description** | 159| | | | | 160+----------+-----------+-----------+-------------------------------------+ 161| 0 | 0 | 1 | Map queue 0 from port 0 to lcore 1. | 162| | | | | 163+----------+-----------+-----------+-------------------------------------+ 164| 1 | 0 | 2 | Map queue 0 from port 1 to lcore 2. | 165| | | | | 166+----------+-----------+-----------+-------------------------------------+ 167 168* The -rule_ipv4 option specifies the reading of IPv4 rules sets from the rule_ipv4.cfg file 169 170* The -rule_ipv6 option specifies the reading of IPv6 rules sets from the rule_ipv6.cfg file. 171 172To use eventdev mode with sync method **ordered** on above mentioned environment, 173Following is the sample command: 174 175.. code-block:: console 176 177 ./<build_dir>/examples/dpdk-l3fwd -l 0-3 -n 4 -a <event device> -- -p 0x3 --eventq-sched=ordered --rule_ipv4="rule_ipv4.cfg" --rule_ipv6="rule_ipv6.cfg" 178 179or 180 181.. code-block:: console 182 183 ./<build_dir>/examples/dpdk-l3fwd -l 0-3 -n 4 -a <event device> \ 184 -- -p 0x03 --mode=eventdev --eventq-sched=ordered --rule_ipv4="rule_ipv4.cfg" --rule_ipv6="rule_ipv6.cfg" 185 186In this command: 187 188* -a option allows the event device supported by platform. 189 The syntax used to indicate this device may vary based on platform. 190 191* The --mode option defines PMD to be used for packet I/O. 192 193* The --eventq-sched option enables synchronization menthod of event queue so that packets will be scheduled accordingly. 194 195If application uses S/W scheduler, it uses following DPDK services: 196 197* Software scheduler 198* Rx adapter service function 199* Tx adapter service function 200 201Application needs service cores to run above mentioned services. Service cores 202must be provided as EAL parameters along with the --vdev=event_sw0 to enable S/W 203scheduler. Following is the sample command: 204 205.. code-block:: console 206 207 ./<build_dir>/examples/dpdk-l3fwd -l 0-7 -s 0xf0000 -n 4 --vdev event_sw0 -- -p 0x3 --mode=eventdev --eventq-sched=ordered --rule_ipv4="rule_ipv4.cfg" --rule_ipv6="rule_ipv6.cfg" 208 209In case of eventdev mode, *--config* option is not used for ethernet port 210configuration. Instead each ethernet port will be configured with mentioned 211setup: 212 213* Single Rx/Tx queue 214 215* Each Rx queue will be connected to event queue via Rx adapter. 216 217* Each Tx queue will be connected via Tx adapter. 218 219Refer to the *DPDK Getting Started Guide* for general information on running applications and 220the Environment Abstraction Layer (EAL) options. 221 222.. _l3_fwd_explanation: 223 224Explanation 225----------- 226 227The following sections provide some explanation of the sample application code. As mentioned in the overview section, 228the initialization and run-time paths are very similar to those of the :doc:`l2_forward_real_virtual` and :doc:`l2_forward_event`. 229The following sections describe aspects that are specific to the L3 Forwarding sample application. 230 231Parse Rules from File 232~~~~~~~~~~~~~~~~~~~~~ 233 234The application parses the rules from the file and adds them to the appropriate route table by calling the appropriate function. 235It ignores empty and comment lines, and parses and validates the rules it reads. 236If errors are detected, the application exits with messages to identify the errors encountered. 237 238The format of the route rules differs based on which lookup method is being used. 239Therefore, the code only decreases the priority number with each rule it parses. 240Route rules are mandatory. 241To read data from the specified file successfully, the application assumes the following: 242 243* Each rule occupies a single line. 244 245* Only the following four rule line types are valid in this application: 246 247* Route rule line, which starts with a leading character 'R' 248 249* Comment line, which starts with a leading character '#' 250 251* Empty line, which consists of a space, form-feed ('\f'), newline ('\n'), 252 carriage return ('\r'), horizontal tab ('\t'), or vertical tab ('\v'). 253 254Other lines types are considered invalid. 255 256* Rules are organized in descending order of priority, 257 which means rules at the head of the file always have a higher priority than those further down in the file. 258 259* A typical IPv4 LPM/FIB rule line should have a format as shown below: 260 261R<destination_ip>/<ip_mask_length><output_port_number> 262 263* A typical IPv4 EM rule line should have a format as shown below: 264 265R<destination_ip><source_ip><destination_port><source_port><protocol><output_port_number> 266 267IPv4 addresses are specified in CIDR format as specified in RFC 4632. 268For LPM/FIB they consist of the dot notation for the address and a prefix length separated by '/'. 269For example, 192.168.0.34/32, where the address is 192.168.0.34 and the prefix length is 32. 270For EM they consist of just the dot notation for the address and no prefix length. 271For example, 192.168.0.34, where the Address is 192.168.0.34. 272EM also includes ports which are specified as a single number which represents a single port. 273 274Hash Initialization 275~~~~~~~~~~~~~~~~~~~ 276 277The hash object is created and loaded with the pre-configured entries read from a global array, 278and then generate the expected 5-tuple as key to keep consistence with those of real flow 279for the convenience to execute hash performance test on 4M/8M/16M flows. 280 281.. note:: 282 283 The Hash initialization will setup both ipv4 and ipv6 hash table, 284 and populate the either table depending on the value of variable ipv6. 285 286.. note:: 287 288 Value of global variable ipv6 can be specified with --ipv6 in the command line. 289 Value of global variable hash_entry_number, 290 which is used to specify the total hash entry number for all used ports in hash performance test, 291 can be specified with --hash-entry-num VALUE in command line, being its default value 4. 292 293.. code-block:: c 294 295 #if (APP_LOOKUP_METHOD == APP_LOOKUP_EXACT_MATCH) 296 297 static void 298 setup_hash(int socketid) 299 { 300 // ... 301 302 if (ipv6 == 0) { 303 /* populate the ipv4 hash */ 304 populate_ipv4_flow_into_table( 305 ipv4_l3fwd_em_lookup_struct[socketid]); 306 } else { 307 /* populate the ipv6 hash */ 308 populate_ipv6_flow_into_table( 309 ipv6_l3fwd_em_lookup_struct[socketid]); 310 } 311 } 312 #endif 313 314LPM Initialization 315~~~~~~~~~~~~~~~~~~ 316 317The LPM object is created and loaded with the pre-configured entries read from a global array. 318 319.. literalinclude:: ../../../examples/l3fwd/l3fwd_em.c 320 :language: c 321 :start-after: Initialize exact match (hash) parameters. 8< 322 :end-before: >8 End of initialization of hash parameters. 323 324FIB Initialization 325~~~~~~~~~~~~~~~~~~ 326 327The FIB object is created and loaded with the pre-configured entries 328read from a global array. 329The abridged code snippet below shows the FIB initialization for IPv4, 330the full setup function including the IPv6 setup can be seen in the app code. 331 332.. literalinclude:: ../../../examples/l3fwd/l3fwd_fib.c 333 :language: c 334 :start-after: Function to setup fib. 8< 335 :end-before: >8 End of setup fib. 336 337Packet Forwarding for Hash-based Lookups 338~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 339 340For each input packet, the packet forwarding operation is done by the l3fwd_simple_forward() 341or simple_ipv4_fwd_4pkts() function for IPv4 packets or the simple_ipv6_fwd_4pkts() function for IPv6 packets. 342The l3fwd_simple_forward() function provides the basic functionality for both IPv4 and IPv6 packet forwarding 343for any number of burst packets received, 344and the packet forwarding decision (that is, the identification of the output interface for the packet) 345for hash-based lookups is done by the get_ipv4_dst_port() or get_ipv6_dst_port() function. 346The get_ipv4_dst_port() function is shown below: 347 348.. literalinclude:: ../../../examples/l3fwd/l3fwd_em.c 349 :language: c 350 :start-after: Performing hash-based lookups. 8< 351 :end-before: >8 End of performing hash-based lookups. 352 353The get_ipv6_dst_port() function is similar to the get_ipv4_dst_port() function. 354 355The simple_ipv4_fwd_4pkts() and simple_ipv6_fwd_4pkts() function are optimized for continuous 4 valid ipv4 and ipv6 packets, 356they leverage the multiple buffer optimization to boost the performance of forwarding packets with the exact match on hash table. 357The key code snippet of simple_ipv4_fwd_4pkts() is shown below: 358 359.. code-block:: c 360 361 static inline void 362 simple_ipv4_fwd_4pkts(struct rte_mbuf* m[4], uint16_t portid, struct lcore_conf *qconf) 363 { 364 // ... 365 366 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))); 367 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))); 368 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))); 369 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))); 370 371 key[0].xmm = _mm_and_si128(data[0], mask0); 372 key[1].xmm = _mm_and_si128(data[1], mask0); 373 key[2].xmm = _mm_and_si128(data[2], mask0); 374 key[3].xmm = _mm_and_si128(data[3], mask0); 375 376 const void *key_array[4] = {&key[0], &key[1], &key[2],&key[3]}; 377 378 rte_hash_lookup_bulk(qconf->ipv4_lookup_struct, &key_array[0], 4, ret); 379 380 dst_port[0] = (ret[0] < 0)? portid:ipv4_l3fwd_out_if[ret[0]]; 381 dst_port[1] = (ret[1] < 0)? portid:ipv4_l3fwd_out_if[ret[1]]; 382 dst_port[2] = (ret[2] < 0)? portid:ipv4_l3fwd_out_if[ret[2]]; 383 dst_port[3] = (ret[3] < 0)? portid:ipv4_l3fwd_out_if[ret[3]]; 384 385 // ... 386 } 387 388The simple_ipv6_fwd_4pkts() function is similar to the simple_ipv4_fwd_4pkts() function. 389 390Known issue: IP packets with extensions or IP packets which are not TCP/UDP cannot work well at this mode. 391 392Packet Forwarding for LPM-based Lookups 393~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 394 395For each input packet, the packet forwarding operation is done by the l3fwd_simple_forward() function, 396but the packet forwarding decision (that is, the identification of the output interface for the packet) 397for LPM-based lookups is done by the get_ipv4_dst_port() function below: 398 399.. literalinclude:: ../../../examples/l3fwd/l3fwd_lpm.c 400 :language: c 401 :start-after: Performing LPM-based lookups. 8< 402 :end-before: >8 End of performing LPM-based lookups. 403 404Packet Forwarding for FIB-based Lookups 405~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 406 407The FIB library was designed to process multiple packets at once, 408it does not have separate functions for single and bulk lookups. 409``rte_fib_lookup_bulk`` is used for IPv4 lookups 410and ``rte_fib6_lookup_bulk`` for IPv6. 411Various examples of these functions being used 412can be found in the sample app code. 413 414Eventdev Driver Initialization 415~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 416Eventdev driver initialization is same as L2 forwarding eventdev application. 417Refer :doc:`l2_forward_event` for more details. 418