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 [--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* ``--max-pkt-len:`` Optional, maximum packet length in decimal (64-9600). 99 100* ``--no-numa:`` Optional, disables numa awareness. 101 102* ``--hash-entry-num:`` Optional, specifies the hash entry number in hexadecimal to be setup. 103 104* ``--ipv6:`` Optional, set if running ipv6 packets. 105 106* ``--parse-ptype:`` Optional, set to use software to analyze packet type. Without this option, hardware will check the packet type. 107 108* ``--per-port-pool:`` Optional, set to use independent buffer pools per port. Without this option, single buffer pool is used for all ports. 109 110* ``--mode:`` Optional, Packet transfer mode for I/O, poll or eventdev. 111 112* ``--eventq-sched:`` Optional, Event queue synchronization method, Ordered, Atomic or Parallel. Only valid if --mode=eventdev. 113 114* ``--event-eth-rxqs:`` Optional, Number of ethernet RX queues per device. Only valid if --mode=eventdev. 115 116* ``-E:`` Optional, enable exact match, 117 legacy flag, please use ``--lookup=em`` instead. 118 119* ``-L:`` Optional, enable longest prefix match, 120 legacy flag, please use ``--lookup=lpm`` instead. 121 122 123For example, consider a dual processor socket platform with 8 physical cores, where cores 0-7 and 16-23 appear on socket 0, 124while cores 8-15 and 24-31 appear on socket 1. 125 126To enable L3 forwarding between two ports, assuming that both ports are in the same socket, using two cores, cores 1 and 2, 127(which are in the same socket too), use the following command: 128 129.. code-block:: console 130 131 ./<build_dir>/examples/dpdk-l3fwd -l 1,2 -n 4 -- -p 0x3 --config="(0,0,1),(1,0,2)" 132 133In this command: 134 135* The -l option enables cores 1, 2 136 137* The -p option enables ports 0 and 1 138 139* The --config option enables one queue on each port and maps each (port,queue) pair to a specific core. 140 The following table shows the mapping in this example: 141 142+----------+-----------+-----------+-------------------------------------+ 143| **Port** | **Queue** | **lcore** | **Description** | 144| | | | | 145+----------+-----------+-----------+-------------------------------------+ 146| 0 | 0 | 1 | Map queue 0 from port 0 to lcore 1. | 147| | | | | 148+----------+-----------+-----------+-------------------------------------+ 149| 1 | 0 | 2 | Map queue 0 from port 1 to lcore 2. | 150| | | | | 151+----------+-----------+-----------+-------------------------------------+ 152 153To use eventdev mode with sync method **ordered** on above mentioned environment, 154Following is the sample command: 155 156.. code-block:: console 157 158 ./<build_dir>/examples/dpdk-l3fwd -l 0-3 -n 4 -a <event device> -- -p 0x3 --eventq-sched=ordered 159 160or 161 162.. code-block:: console 163 164 ./<build_dir>/examples/dpdk-l3fwd -l 0-3 -n 4 -a <event device> \ 165 -- -p 0x03 --mode=eventdev --eventq-sched=ordered 166 167In this command: 168 169* -a option allows the event device supported by platform. 170 The syntax used to indicate this device may vary based on platform. 171 172* The --mode option defines PMD to be used for packet I/O. 173 174* The --eventq-sched option enables synchronization menthod of event queue so that packets will be scheduled accordingly. 175 176If application uses S/W scheduler, it uses following DPDK services: 177 178* Software scheduler 179* Rx adapter service function 180* Tx adapter service function 181 182Application needs service cores to run above mentioned services. Service cores 183must be provided as EAL parameters along with the --vdev=event_sw0 to enable S/W 184scheduler. Following is the sample command: 185 186.. code-block:: console 187 188 ./<build_dir>/examples/dpdk-l3fwd -l 0-7 -s 0xf0000 -n 4 --vdev event_sw0 -- -p 0x3 --mode=eventdev --eventq-sched=ordered 189 190In case of eventdev mode, *--config* option is not used for ethernet port 191configuration. Instead each ethernet port will be configured with mentioned 192setup: 193 194* Single Rx/Tx queue 195 196* Each Rx queue will be connected to event queue via Rx adapter. 197 198* Each Tx queue will be connected via Tx adapter. 199 200Refer to the *DPDK Getting Started Guide* for general information on running applications and 201the Environment Abstraction Layer (EAL) options. 202 203.. _l3_fwd_explanation: 204 205Explanation 206----------- 207 208The following sections provide some explanation of the sample application code. As mentioned in the overview section, 209the initialization and run-time paths are very similar to those of the :doc:`l2_forward_real_virtual` and :doc:`l2_forward_event`. 210The following sections describe aspects that are specific to the L3 Forwarding sample application. 211 212Hash Initialization 213~~~~~~~~~~~~~~~~~~~ 214 215The hash object is created and loaded with the pre-configured entries read from a global array, 216and then generate the expected 5-tuple as key to keep consistence with those of real flow 217for the convenience to execute hash performance test on 4M/8M/16M flows. 218 219.. note:: 220 221 The Hash initialization will setup both ipv4 and ipv6 hash table, 222 and populate the either table depending on the value of variable ipv6. 223 To support the hash performance test with up to 8M single direction flows/16M bi-direction flows, 224 populate_ipv4_many_flow_into_table() function will populate the hash table with specified hash table entry number(default 4M). 225 226.. note:: 227 228 Value of global variable ipv6 can be specified with --ipv6 in the command line. 229 Value of global variable hash_entry_number, 230 which is used to specify the total hash entry number for all used ports in hash performance test, 231 can be specified with --hash-entry-num VALUE in command line, being its default value 4. 232 233.. code-block:: c 234 235 #if (APP_LOOKUP_METHOD == APP_LOOKUP_EXACT_MATCH) 236 237 static void 238 setup_hash(int socketid) 239 { 240 // ... 241 242 if (hash_entry_number != HASH_ENTRY_NUMBER_DEFAULT) { 243 if (ipv6 == 0) { 244 /* populate the ipv4 hash */ 245 populate_ipv4_many_flow_into_table(ipv4_l3fwd_lookup_struct[socketid], hash_entry_number); 246 } else { 247 /* populate the ipv6 hash */ 248 populate_ipv6_many_flow_into_table( ipv6_l3fwd_lookup_struct[socketid], hash_entry_number); 249 } 250 } else 251 if (ipv6 == 0) { 252 /* populate the ipv4 hash */ 253 populate_ipv4_few_flow_into_table(ipv4_l3fwd_lookup_struct[socketid]); 254 } else { 255 /* populate the ipv6 hash */ 256 populate_ipv6_few_flow_into_table(ipv6_l3fwd_lookup_struct[socketid]); 257 } 258 } 259 } 260 #endif 261 262LPM Initialization 263~~~~~~~~~~~~~~~~~~ 264 265The LPM object is created and loaded with the pre-configured entries read from a global array. 266 267.. literalinclude:: ../../../examples/l3fwd/l3fwd_em.c 268 :language: c 269 :start-after: Initialize exact match (hash) parameters. 8< 270 :end-before: >8 End of initialization of hash parameters. 271 272FIB Initialization 273~~~~~~~~~~~~~~~~~~ 274 275The FIB object is created and loaded with the pre-configured entries 276read from a global array. 277The abridged code snippet below shows the FIB initialization for IPv4, 278the full setup function including the IPv6 setup can be seen in the app code. 279 280.. literalinclude:: ../../../examples/l3fwd/l3fwd_fib.c 281 :language: c 282 :start-after: Function to setup fib. 8< 283 :end-before: >8 End of setup fib. 284 285Packet Forwarding for Hash-based Lookups 286~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 287 288For each input packet, the packet forwarding operation is done by the l3fwd_simple_forward() 289or simple_ipv4_fwd_4pkts() function for IPv4 packets or the simple_ipv6_fwd_4pkts() function for IPv6 packets. 290The l3fwd_simple_forward() function provides the basic functionality for both IPv4 and IPv6 packet forwarding 291for any number of burst packets received, 292and the packet forwarding decision (that is, the identification of the output interface for the packet) 293for hash-based lookups is done by the get_ipv4_dst_port() or get_ipv6_dst_port() function. 294The get_ipv4_dst_port() function is shown below: 295 296.. literalinclude:: ../../../examples/l3fwd/l3fwd_em.c 297 :language: c 298 :start-after: Performing hash-based lookups. 8< 299 :end-before: >8 End of performing hash-based lookups. 300 301The get_ipv6_dst_port() function is similar to the get_ipv4_dst_port() function. 302 303The simple_ipv4_fwd_4pkts() and simple_ipv6_fwd_4pkts() function are optimized for continuous 4 valid ipv4 and ipv6 packets, 304they leverage the multiple buffer optimization to boost the performance of forwarding packets with the exact match on hash table. 305The key code snippet of simple_ipv4_fwd_4pkts() is shown below: 306 307.. code-block:: c 308 309 static inline void 310 simple_ipv4_fwd_4pkts(struct rte_mbuf* m[4], uint16_t portid, struct lcore_conf *qconf) 311 { 312 // ... 313 314 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))); 315 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))); 316 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))); 317 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))); 318 319 key[0].xmm = _mm_and_si128(data[0], mask0); 320 key[1].xmm = _mm_and_si128(data[1], mask0); 321 key[2].xmm = _mm_and_si128(data[2], mask0); 322 key[3].xmm = _mm_and_si128(data[3], mask0); 323 324 const void *key_array[4] = {&key[0], &key[1], &key[2],&key[3]}; 325 326 rte_hash_lookup_bulk(qconf->ipv4_lookup_struct, &key_array[0], 4, ret); 327 328 dst_port[0] = (ret[0] < 0)? portid:ipv4_l3fwd_out_if[ret[0]]; 329 dst_port[1] = (ret[1] < 0)? portid:ipv4_l3fwd_out_if[ret[1]]; 330 dst_port[2] = (ret[2] < 0)? portid:ipv4_l3fwd_out_if[ret[2]]; 331 dst_port[3] = (ret[3] < 0)? portid:ipv4_l3fwd_out_if[ret[3]]; 332 333 // ... 334 } 335 336The simple_ipv6_fwd_4pkts() function is similar to the simple_ipv4_fwd_4pkts() function. 337 338Known issue: IP packets with extensions or IP packets which are not TCP/UDP cannot work well at this mode. 339 340Packet Forwarding for LPM-based Lookups 341~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 342 343For each input packet, the packet forwarding operation is done by the l3fwd_simple_forward() function, 344but the packet forwarding decision (that is, the identification of the output interface for the packet) 345for LPM-based lookups is done by the get_ipv4_dst_port() function below: 346 347.. literalinclude:: ../../../examples/l3fwd/l3fwd_lpm.c 348 :language: c 349 :start-after: Performing LPM-based lookups. 8< 350 :end-before: >8 End of performing LPM-based lookups. 351 352Packet Forwarding for FIB-based Lookups 353~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 354 355The FIB library was designed to process multiple packets at once, 356it does not have separate functions for single and bulk lookups. 357``rte_fib_lookup_bulk`` is used for IPv4 lookups 358and ``rte_fib6_lookup_bulk`` for IPv6. 359Various examples of these functions being used 360can be found in the sample app code. 361 362Eventdev Driver Initialization 363~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 364Eventdev driver initialization is same as L2 forwarding eventdev application. 365Refer :doc:`l2_forward_event` for more details. 366