xref: /dpdk/doc/guides/sample_app_ug/ipv4_multicast.rst (revision 131a75b6e4df60586103d71defb85dcf9f77fb17)
1..  BSD LICENSE
2    Copyright(c) 2010-2014 Intel Corporation. All rights reserved.
3    All rights reserved.
4
5    Redistribution and use in source and binary forms, with or without
6    modification, are permitted provided that the following conditions
7    are met:
8
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
14    distribution.
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.
18
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.
30
31IPv4 Multicast Sample Application
32=================================
33
34The IPv4 Multicast application is a simple example of packet processing
35using the Data Plane Development Kit (DPDK).
36The application performs L3 multicasting.
37
38Overview
39--------
40
41The application demonstrates the use of zero-copy buffers for packet forwarding.
42The initialization and run-time paths are very similar to those of the :doc:`l2_forward_real_virtual`.
43This guide highlights the differences between the two applications.
44There are two key differences from the L2 Forwarding sample application:
45
46*   The IPv4 Multicast sample application makes use of indirect buffers.
47
48*   The forwarding decision is taken based on information read from the input packet's IPv4 header.
49
50The lookup method is the Four-byte Key (FBK) hash-based method.
51The lookup table is composed of pairs of destination IPv4 address (the FBK)
52and a port mask associated with that IPv4 address.
53
54.. note::
55
56    The max port mask supported in the given hash table is 0xf, so only first
57    four ports can be supported.
58    If using non-consecutive ports, use the destination IPv4 address accordingly.
59
60For convenience and simplicity, this sample application does not take IANA-assigned multicast addresses into account,
61but instead equates the last four bytes of the multicast group (that is, the last four bytes of the destination IP address)
62with the mask of ports to multicast packets to.
63Also, the application does not consider the Ethernet addresses;
64it looks only at the IPv4 destination address for any given packet.
65
66Compiling the Application
67-------------------------
68
69To compile the sample application see :doc:`compiling`.
70
71The application is located in the ``ipv4_multicast`` sub-directory.
72
73Running the Application
74-----------------------
75
76The application has a number of command line options:
77
78.. code-block:: console
79
80    ./build/ipv4_multicast [EAL options] -- -p PORTMASK [-q NQ]
81
82where,
83
84*   -p PORTMASK: Hexadecimal bitmask of ports to configure
85
86*   -q NQ: determines the number of queues per lcore
87
88.. note::
89
90    Unlike the basic L2/L3 Forwarding sample applications,
91    NUMA support is not provided in the IPv4 Multicast sample application.
92
93Typically, to run the IPv4 Multicast sample application, issue the following command (as root):
94
95.. code-block:: console
96
97    ./build/ipv4_multicast -l 0-3 -n 3 -- -p 0x3 -q 1
98
99In this command:
100
101*   The -l option enables cores 0, 1, 2 and 3
102
103*   The -n option specifies 3 memory channels
104
105*   The -p option enables ports 0 and 1
106
107*   The -q option assigns 1 queue to each lcore
108
109Refer to the *DPDK Getting Started Guide* for general information on running applications
110and the Environment Abstraction Layer (EAL) options.
111
112Explanation
113-----------
114
115The following sections provide some explanation of the code.
116As mentioned in the overview section,
117the initialization and run-time paths are very similar to those of the :doc:`l2_forward_real_virtual`.
118The following sections describe aspects that are specific to the IPv4 Multicast sample application.
119
120Memory Pool Initialization
121~~~~~~~~~~~~~~~~~~~~~~~~~~
122
123The IPv4 Multicast sample application uses three memory pools.
124Two of the pools are for indirect buffers used for packet duplication purposes.
125Memory pools for indirect buffers are initialized differently from the memory pool for direct buffers:
126
127.. code-block:: c
128
129    packet_pool = rte_pktmbuf_pool_create("packet_pool", NB_PKT_MBUF, 32,
130			0, PKT_MBUF_DATA_SIZE, rte_socket_id());
131    header_pool = rte_pktmbuf_pool_create("header_pool", NB_HDR_MBUF, 32,
132			0, HDR_MBUF_DATA_SIZE, rte_socket_id());
133    clone_pool = rte_pktmbuf_pool_create("clone_pool", NB_CLONE_MBUF, 32,
134			0, 0, rte_socket_id());
135
136The reason for this is because indirect buffers are not supposed to hold any packet data and
137therefore can be initialized with lower amount of reserved memory for each buffer.
138
139Hash Initialization
140~~~~~~~~~~~~~~~~~~~
141
142The hash object is created and loaded with the pre-configured entries read from a global array:
143
144.. code-block:: c
145
146    static int
147
148    init_mcast_hash(void)
149    {
150        uint32_t i;
151        mcast_hash_params.socket_id = rte_socket_id();
152
153        mcast_hash = rte_fbk_hash_create(&mcast_hash_params);
154        if (mcast_hash == NULL){
155            return -1;
156        }
157
158        for (i = 0; i < N_MCAST_GROUPS; i ++){
159            if (rte_fbk_hash_add_key(mcast_hash, mcast_group_table[i].ip, mcast_group_table[i].port_mask) < 0) {
160		        return -1;
161            }
162        }
163        return 0;
164    }
165
166Forwarding
167~~~~~~~~~~
168
169All forwarding is done inside the mcast_forward() function.
170Firstly, the Ethernet* header is removed from the packet and the IPv4 address is extracted from the IPv4 header:
171
172.. code-block:: c
173
174    /* Remove the Ethernet header from the input packet */
175
176    iphdr = (struct ipv4_hdr *)rte_pktmbuf_adj(m, sizeof(struct ether_hdr));
177    RTE_ASSERT(iphdr != NULL);
178    dest_addr = rte_be_to_cpu_32(iphdr->dst_addr);
179
180Then, the packet is checked to see if it has a multicast destination address and
181if the routing table has any ports assigned to the destination address:
182
183.. code-block:: c
184
185    if (!IS_IPV4_MCAST(dest_addr) ||
186       (hash = rte_fbk_hash_lookup(mcast_hash, dest_addr)) <= 0 ||
187       (port_mask = hash & enabled_port_mask) == 0) {
188           rte_pktmbuf_free(m);
189           return;
190    }
191
192Then, the number of ports in the destination portmask is calculated with the help of the bitcnt() function:
193
194.. code-block:: c
195
196    /* Get number of bits set. */
197
198    static inline uint32_t bitcnt(uint32_t v)
199    {
200        uint32_t n;
201
202        for (n = 0; v != 0; v &= v - 1, n++)
203           ;
204        return n;
205    }
206
207This is done to determine which forwarding algorithm to use.
208This is explained in more detail in the next section.
209
210Thereafter, a destination Ethernet address is constructed:
211
212.. code-block:: c
213
214    /* construct destination Ethernet address */
215
216    dst_eth_addr = ETHER_ADDR_FOR_IPV4_MCAST(dest_addr);
217
218Since Ethernet addresses are also part of the multicast process, each outgoing packet carries the same destination Ethernet address.
219The destination Ethernet address is constructed from the lower 23 bits of the multicast group OR-ed
220with the Ethernet address 01:00:5e:00:00:00, as per RFC 1112:
221
222.. code-block:: c
223
224    #define ETHER_ADDR_FOR_IPV4_MCAST(x) \
225        (rte_cpu_to_be_64(0x01005e000000ULL | ((x) & 0x7fffff)) >> 16)
226
227Then, packets are dispatched to the destination ports according to the portmask associated with a multicast group:
228
229.. code-block:: c
230
231    for (port = 0; use_clone != port_mask; port_mask >>= 1, port++) {
232        /* Prepare output packet and send it out. */
233
234        if ((port_mask & 1) != 0) {
235            if (likely ((mc = mcast_out_pkt(m, use_clone)) != NULL))
236                mcast_send_pkt(mc, &dst_eth_addr.as_addr, qconf, port);
237            else if (use_clone == 0)
238                 rte_pktmbuf_free(m);
239       }
240    }
241
242The actual packet transmission is done in the mcast_send_pkt() function:
243
244.. code-block:: c
245
246    static inline void mcast_send_pkt(struct rte_mbuf *pkt, struct ether_addr *dest_addr, struct lcore_queue_conf *qconf, uint16_t port)
247    {
248        struct ether_hdr *ethdr;
249        uint16_t len;
250
251        /* Construct Ethernet header. */
252
253        ethdr = (struct ether_hdr *)rte_pktmbuf_prepend(pkt, (uint16_t) sizeof(*ethdr));
254
255        RTE_ASSERT(ethdr != NULL);
256
257        ether_addr_copy(dest_addr, &ethdr->d_addr);
258        ether_addr_copy(&ports_eth_addr[port], &ethdr->s_addr);
259        ethdr->ether_type = rte_be_to_cpu_16(ETHER_TYPE_IPv4);
260
261        /* Put new packet into the output queue */
262
263        len = qconf->tx_mbufs[port].len;
264        qconf->tx_mbufs[port].m_table[len] = pkt;
265        qconf->tx_mbufs[port].len = ++len;
266
267        /* Transmit packets */
268
269        if (unlikely(MAX_PKT_BURST == len))
270            send_burst(qconf, port);
271    }
272
273Buffer Cloning
274~~~~~~~~~~~~~~
275
276This is the most important part of the application since it demonstrates the use of zero- copy buffer cloning.
277There are two approaches for creating the outgoing packet and although both are based on the data zero-copy idea,
278there are some differences in the detail.
279
280The first approach creates a clone of the input packet, for example,
281walk though all segments of the input packet and for each of segment,
282create a new buffer and attach that new buffer to the segment
283(refer to rte_pktmbuf_clone() in the rte_mbuf library for more details).
284A new buffer is then allocated for the packet header and is prepended to the cloned buffer.
285
286The second approach does not make a clone, it just increments the reference counter for all input packet segment,
287allocates a new buffer for the packet header and prepends it to the input packet.
288
289Basically, the first approach reuses only the input packet's data, but creates its own copy of packet's metadata.
290The second approach reuses both input packet's data and metadata.
291
292The advantage of first approach is that each outgoing packet has its own copy of the metadata,
293so we can safely modify the data pointer of the input packet.
294That allows us to skip creation if the output packet is for the last destination port
295and instead modify input packet's header in place.
296For example, for N destination ports, we need to invoke mcast_out_pkt() (N-1) times.
297
298The advantage of the second approach is that there is less work to be done for each outgoing packet,
299that is, the "clone" operation is skipped completely.
300However, there is a price to pay.
301The input packet's metadata must remain intact, so for N destination ports,
302we need to invoke mcast_out_pkt() (N) times.
303
304Therefore, for a small number of outgoing ports (and segments in the input packet),
305first approach is faster.
306As the number of outgoing ports (and/or input segments) grows, the second approach becomes more preferable.
307
308Depending on the number of segments or the number of ports in the outgoing portmask,
309either the first (with cloning) or the second (without cloning) approach is taken:
310
311.. code-block:: c
312
313    use_clone = (port_num <= MCAST_CLONE_PORTS && m->pkt.nb_segs <= MCAST_CLONE_SEGS);
314
315It is the mcast_out_pkt() function that performs the packet duplication (either with or without actually cloning the buffers):
316
317.. code-block:: c
318
319    static inline struct rte_mbuf *mcast_out_pkt(struct rte_mbuf *pkt, int use_clone)
320    {
321        struct rte_mbuf *hdr;
322
323        /* Create new mbuf for the header. */
324
325        if (unlikely ((hdr = rte_pktmbuf_alloc(header_pool)) == NULL))
326            return NULL;
327
328        /* If requested, then make a new clone packet. */
329
330        if (use_clone != 0 && unlikely ((pkt = rte_pktmbuf_clone(pkt, clone_pool)) == NULL)) {
331            rte_pktmbuf_free(hdr);
332            return NULL;
333        }
334
335        /* prepend new header */
336
337        hdr->pkt.next = pkt;
338
339        /* update header's fields */
340
341        hdr->pkt.pkt_len = (uint16_t)(hdr->pkt.data_len + pkt->pkt.pkt_len);
342        hdr->pkt.nb_segs = pkt->pkt.nb_segs + 1;
343
344        /* copy metadata from source packet */
345
346        hdr->pkt.in_port = pkt->pkt.in_port;
347        hdr->pkt.vlan_macip = pkt->pkt.vlan_macip;
348        hdr->pkt.hash = pkt->pkt.hash;
349        hdr->ol_flags = pkt->ol_flags;
350        rte_mbuf_sanity_check(hdr, RTE_MBUF_PKT, 1);
351
352        return hdr;
353    }
354