-.. BSD LICENSE
- Copyright(c) 2010-2014 Intel Corporation. All rights reserved.
- All rights reserved.
-
- Redistribution and use in source and binary forms, with or without
- modification, are permitted provided that the following conditions
- are met:
-
- * Redistributions of source code must retain the above copyright
- notice, this list of conditions and the following disclaimer.
- * Redistributions in binary form must reproduce the above copyright
- notice, this list of conditions and the following disclaimer in
- the documentation and/or other materials provided with the
- distribution.
- * Neither the name of Intel Corporation nor the names of its
- contributors may be used to endorse or promote products derived
- from this software without specific prior written permission.
-
- THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
- "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
- LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
- A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
- OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
- SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
- LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
- DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
- THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
- (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
- OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+.. SPDX-License-Identifier: BSD-3-Clause
+ Copyright(c) 2010-2014 Intel Corporation.
.. _Mbuf_Library:
============
The mbuf library provides the ability to allocate and free buffers (mbufs)
-that may be used by the Intel® DPDK application to store message buffers.
+that may be used by the DPDK application to store message buffers.
The message buffers are stored in a mempool, using the :ref:`Mempool Library <Mempool_Library>`.
-A rte_mbuf struct can carry network packet buffers (type is RTE_MBUF_PKT)
-or generic control buffers (type is RTE_MBUF_CTRL).
-This can be extended to other types.
-The rte_mbuf is kept as small as possible (one cache line if possible).
+A rte_mbuf struct generally carries network packet buffers, but it can actually
+be any data (control data, events, ...).
+The rte_mbuf header structure is kept as small as possible and currently uses
+just two cache lines, with the most frequently used fields being on the first
+of the two cache lines.
Design of Packet Buffers
------------------------
On the other hand, the second method is more flexible and allows
the complete separation of the allocation of metadata structures from the allocation of packet data buffers.
-The first method was chosen for the Intel® DPDK.
+The first method was chosen for the DPDK.
The metadata contains control information such as message type, length,
-pointer to the start of the data and a pointer for additional mbuf structures allowing buffer chaining.
+offset to the start of the data and a pointer for additional mbuf structures allowing buffer chaining.
Message buffers that are used to carry network packets can handle buffer chaining
where multiple buffers are required to hold the complete packet.
-This is the case for jumbo frames that are composed of many mbufs linked together through their pkt.next field.
+This is the case for jumbo frames that are composed of many mbufs linked together through their next field.
For a newly allocated mbuf, the area at which the data begins in the message buffer is
RTE_PKTMBUF_HEADROOM bytes after the beginning of the buffer, which is cache aligned.
Message buffers may be used to carry control information, packets, events,
and so on between different entities in the system.
-Message buffers may also use their data pointers to point to other message buffer data sections or other structures.
+Message buffers may also use their buffer pointers to point to other message buffer data sections or other structures.
-Figure 8 and Figure 9 show some of these scenarios.
+:numref:`figure_mbuf1` and :numref:`figure_mbuf2` show some of these scenarios.
-.. _pg_figure_8:
+.. _figure_mbuf1:
-**Figure 8. An mbuf with One Segment**
+.. figure:: img/mbuf1.*
-.. image22_png has been replaced
+ An mbuf with One Segment
-|mbuf1|
-.. _pg_figure_9:
+.. _figure_mbuf2:
-**Figure 9. An mbuf with Three Segments**
+.. figure:: img/mbuf2.*
-.. image23_png has been replaced
+ An mbuf with Three Segments
-|mbuf2|
The Buffer Manager implements a fairly standard set of buffer access functions to manipulate network packets.
The Buffer Manager uses the :ref:`Mempool Library <Mempool_Library>` to allocate buffers.
Therefore, it ensures that the packet header is interleaved optimally across the channels and ranks for L3 processing.
An mbuf contains a field indicating the pool that it originated from.
-When calling rte_ctrlmbuf_free(m) or rte_pktmbuf_free(m), the mbuf returns to its original pool.
+When calling rte_pktmbuf_free(m), the mbuf returns to its original pool.
Constructors
------------
-Packet and control mbuf constructors are provided by the API.
-The rte_pktmbuf_init() and rte_ctrlmbuf_init() functions initialize some fields in the mbuf structure that
+Packet mbuf constructors are provided by the API.
+The rte_pktmbuf_init() function initializes some fields in the mbuf structure that
are not modified by the user once created (mbuf type, origin pool, buffer start address, and so on).
This function is given as a callback function to the rte_mempool_create() function at pool creation time.
----------------------------
Allocating a new mbuf requires the user to specify the mempool from which the mbuf should be taken.
-For a packet mbuf, it contains one segment, with a length of 0.
-The pointer to data is initialized to have some bytes of headroom in the buffer (RTE_PKTMBUF_HEADROOM).
-For a control mbuf, it is initialized with data pointing to the beginning of the buffer and a length of zero.
+For any newly-allocated mbuf, it contains one segment, with a length of 0.
+The offset to data is initialized to have some bytes of headroom in the buffer (RTE_PKTMBUF_HEADROOM).
Freeing a mbuf means returning it into its original mempool.
The content of an mbuf is not modified when it is stored in a pool (as a free mbuf).
* Remove data at the beginning of the buffer (rte_pktmbuf_adj())
- * Remove data at the end of the buffer (rte_pktmbuf_trim()) Refer to the *Intel® DPDK API Reference* for details.
+ * Remove data at the end of the buffer (rte_pktmbuf_trim()) Refer to the *DPDK API Reference* for details.
Meta Information
----------------
For chained buffers, only the first mbuf of the chain stores this meta information.
+For instance, this is the case on RX side for the IEEE1588 packet
+timestamp mechanism, the VLAN tagging and the IP checksum computation.
+
+On TX side, it is also possible for an application to delegate some
+processing to the hardware if it supports it. For instance, the
+PKT_TX_IP_CKSUM flag allows to offload the computation of the IPv4
+checksum.
+
+The following examples explain how to configure different TX offloads on
+a vxlan-encapsulated tcp packet:
+``out_eth/out_ip/out_udp/vxlan/in_eth/in_ip/in_tcp/payload``
+
+- calculate checksum of out_ip::
+
+ mb->l2_len = len(out_eth)
+ mb->l3_len = len(out_ip)
+ mb->ol_flags |= PKT_TX_IPV4 | PKT_TX_IP_CSUM
+ set out_ip checksum to 0 in the packet
+
+ This is supported on hardware advertising DEV_TX_OFFLOAD_IPV4_CKSUM.
+
+- calculate checksum of out_ip and out_udp::
+
+ mb->l2_len = len(out_eth)
+ mb->l3_len = len(out_ip)
+ mb->ol_flags |= PKT_TX_IPV4 | PKT_TX_IP_CSUM | PKT_TX_UDP_CKSUM
+ set out_ip checksum to 0 in the packet
+ set out_udp checksum to pseudo header using rte_ipv4_phdr_cksum()
+
+ This is supported on hardware advertising DEV_TX_OFFLOAD_IPV4_CKSUM
+ and DEV_TX_OFFLOAD_UDP_CKSUM.
+
+- calculate checksum of in_ip::
+
+ mb->l2_len = len(out_eth + out_ip + out_udp + vxlan + in_eth)
+ mb->l3_len = len(in_ip)
+ mb->ol_flags |= PKT_TX_IPV4 | PKT_TX_IP_CSUM
+ set in_ip checksum to 0 in the packet
+
+ This is similar to case 1), but l2_len is different. It is supported
+ on hardware advertising DEV_TX_OFFLOAD_IPV4_CKSUM.
+ Note that it can only work if outer L4 checksum is 0.
+
+- calculate checksum of in_ip and in_tcp::
+
+ mb->l2_len = len(out_eth + out_ip + out_udp + vxlan + in_eth)
+ mb->l3_len = len(in_ip)
+ mb->ol_flags |= PKT_TX_IPV4 | PKT_TX_IP_CSUM | PKT_TX_TCP_CKSUM
+ set in_ip checksum to 0 in the packet
+ set in_tcp checksum to pseudo header using rte_ipv4_phdr_cksum()
+
+ This is similar to case 2), but l2_len is different. It is supported
+ on hardware advertising DEV_TX_OFFLOAD_IPV4_CKSUM and
+ DEV_TX_OFFLOAD_TCP_CKSUM.
+ Note that it can only work if outer L4 checksum is 0.
+
+- segment inner TCP::
+
+ mb->l2_len = len(out_eth + out_ip + out_udp + vxlan + in_eth)
+ mb->l3_len = len(in_ip)
+ mb->l4_len = len(in_tcp)
+ mb->ol_flags |= PKT_TX_IPV4 | PKT_TX_IP_CKSUM | PKT_TX_TCP_CKSUM |
+ PKT_TX_TCP_SEG;
+ set in_ip checksum to 0 in the packet
+ set in_tcp checksum to pseudo header without including the IP
+ payload length using rte_ipv4_phdr_cksum()
+
+ This is supported on hardware advertising DEV_TX_OFFLOAD_TCP_TSO.
+ Note that it can only work if outer L4 checksum is 0.
+
+- calculate checksum of out_ip, in_ip, in_tcp::
+
+ mb->outer_l2_len = len(out_eth)
+ mb->outer_l3_len = len(out_ip)
+ mb->l2_len = len(out_udp + vxlan + in_eth)
+ mb->l3_len = len(in_ip)
+ mb->ol_flags |= PKT_TX_OUTER_IPV4 | PKT_TX_OUTER_IP_CKSUM | \
+ PKT_TX_IP_CKSUM | PKT_TX_TCP_CKSUM;
+ set out_ip checksum to 0 in the packet
+ set in_ip checksum to 0 in the packet
+ set in_tcp checksum to pseudo header using rte_ipv4_phdr_cksum()
+
+ This is supported on hardware advertising DEV_TX_OFFLOAD_IPV4_CKSUM,
+ DEV_TX_OFFLOAD_UDP_CKSUM and DEV_TX_OFFLOAD_OUTER_IPV4_CKSUM.
+
+The list of flags and their precise meaning is described in the mbuf API
+documentation (rte_mbuf.h). Also refer to the testpmd source code
+(specifically the csumonly.c file) for details.
+
+.. _direct_indirect_buffer:
+
Direct and Indirect Buffers
---------------------------
A direct buffer is a buffer that is completely separate and self-contained.
-An indirect buffer behaves like a direct buffer but for the fact that the data pointer it contains points to data in another direct buffer.
+An indirect buffer behaves like a direct buffer but for the fact that the buffer pointer and
+data offset in it refer to data in another direct buffer.
This is useful in situations where packets need to be duplicated or fragmented,
since indirect buffers provide the means to reuse the same packet data across multiple buffers.
If the resulting reference counter is equal to 0, the direct buffer is freed since it is no longer in use.
There are a few things to remember when dealing with indirect buffers.
-First of all, it is not possible to attach an indirect buffer to another indirect buffer.
+First of all, an indirect buffer is never attached to another indirect buffer.
+Attempting to attach buffer A to indirect buffer B that is attached to C, makes rte_pktmbuf_attach() automatically attach A to C, effectively cloning B.
Secondly, for a buffer to become indirect, its reference counter must be equal to 1,
that is, it must not be already referenced by another indirect buffer.
Finally, it is not possible to reattach an indirect buffer to the direct buffer (unless it is detached first).
---------
All networking application should use mbufs to transport network packets.
-
-.. |mbuf1| image:: img/mbuf1.svg
-
-.. |mbuf2| image:: img/mbuf2.svg
git.droids-corp.org / dpdk.git / blobdiff