2 Copyright(c) 2010-2014 Intel Corporation. All rights reserved.
5 Redistribution and use in source and binary forms, with or without
6 modification, are permitted provided that the following conditions
9 * Redistributions of source code must retain the above copyright
10 notice, this list of conditions and the following disclaimer.
11 * Redistributions in binary form must reproduce the above copyright
12 notice, this list of conditions and the following disclaimer in
13 the documentation and/or other materials provided with the
15 * Neither the name of Intel Corporation nor the names of its
16 contributors may be used to endorse or promote products derived
17 from this software without specific prior written permission.
19 THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
20 "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
21 LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
22 A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
23 OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
24 SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
25 LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
26 DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
27 THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
28 (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
29 OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
31 Distributor Sample Application
32 ==============================
34 The distributor sample application is a simple example of packet distribution
35 to cores using the Data Plane Development Kit (DPDK).
40 The distributor application performs the distribution of packets that are received
41 on an RX_PORT to different cores. When processed by the cores, the destination
42 port of a packet is the port from the enabled port mask adjacent to the one on
43 which the packet was received, that is, if the first four ports are enabled
44 (port mask 0xf), ports 0 and 1 RX/TX into each other, and ports 2 and 3 RX/TX
47 This application can be used to benchmark performance using the traffic
48 generator as shown in the figure below.
52 .. figure:: img/dist_perf.*
54 Performance Benchmarking Setup (Basic Environment)
57 Compiling the Application
58 -------------------------
60 #. Go to the sample application directory:
62 .. code-block:: console
64 export RTE_SDK=/path/to/rte_sdk
65 cd ${RTE_SDK}/examples/distributor
67 #. Set the target (a default target is used if not specified). For example:
69 .. code-block:: console
71 export RTE_TARGET=x86_64-native-linuxapp-gcc
73 See the DPDK Getting Started Guide for possible RTE_TARGET values.
75 #. Build the application:
77 .. code-block:: console
81 Running the Application
82 -----------------------
84 #. The application has a number of command line options:
86 .. code-block:: console
88 ./build/distributor_app [EAL options] -- -p PORTMASK
92 * -p PORTMASK: Hexadecimal bitmask of ports to configure
94 #. To run the application in linuxapp environment with 10 lcores, 4 ports,
97 .. code-block:: console
99 $ ./build/distributor_app -c 0x4003fe -n 4 -- -p f
101 #. Refer to the DPDK Getting Started Guide for general information on running
102 applications and the Environment Abstraction Layer (EAL) options.
107 The distributor application consists of three types of threads: a receive
108 thread (lcore_rx()), a set of worker threads(lcore_worker())
109 and a transmit thread(lcore_tx()). How these threads work together is shown
110 in :numref:`figure_dist_app` below. The main() function launches threads of these three types.
111 Each thread has a while loop which will be doing processing and which is
112 terminated only upon SIGINT or ctrl+C. The receive and transmit threads
113 communicate using a software ring (rte_ring structure).
115 The receive thread receives the packets using rte_eth_rx_burst() and gives
116 them to the distributor (using rte_distributor_process() API) which will
117 be called in context of the receive thread itself. The distributor distributes
118 the packets to workers threads based on the tagging of the packet -
119 indicated by the hash field in the mbuf. For IP traffic, this field is
120 automatically filled by the NIC with the "usr" hash value for the packet,
121 which works as a per-flow tag.
123 More than one worker thread can exist as part of the application, and these
124 worker threads do simple packet processing by requesting packets from
125 the distributor, doing a simple XOR operation on the input port mbuf field
126 (to indicate the output port which will be used later for packet transmission)
127 and then finally returning the packets back to the distributor in the RX thread.
129 Meanwhile, the receive thread will call the distributor api
130 rte_distributor_returned_pkts() to get the packets processed, and will enqueue
131 them to a ring for transfer to the TX thread for transmission on the output port.
132 The transmit thread will dequeue the packets from the ring and transmit them on
133 the output port specified in packet mbuf.
135 Users who wish to terminate the running of the application have to press ctrl+C
136 (or send SIGINT to the app). Upon this signal, a signal handler provided
137 in the application will terminate all running threads gracefully and print
138 final statistics to the user.
142 .. figure:: img/dist_app.*
144 Distributor Sample Application Layout
147 Debug Logging Support
148 ---------------------
150 Debug logging is provided as part of the application; the user needs to uncomment
151 the line "#define DEBUG" defined in start of the application in main.c to enable debug logs.
156 Upon SIGINT (or) ctrl+C, the print_stats() function displays the count of packets
157 processed at the different stages in the application.
159 Application Initialization
160 --------------------------
162 Command line parsing is done in the same way as it is done in the L2 Forwarding Sample
163 Application. See Section 9.4.1, "Command Line Arguments".
165 Mbuf pool initialization is done in the same way as it is done in the L2 Forwarding
166 Sample Application. See Section 9.4.2, "Mbuf Pool Initialization".
168 Driver Initialization is done in same way as it is done in the L2 Forwarding Sample
169 Application. See Section 9.4.3, "Driver Initialization".
171 RX queue initialization is done in the same way as it is done in the L2 Forwarding
172 Sample Application. See Section 9.4.4, "RX Queue Initialization".
174 TX queue initialization is done in the same way as it is done in the L2 Forwarding
175 Sample Application. See Section 9.4.5, "TX Queue Initialization".