rte_eth_rxseg_split(3)

💅 NAME 💅

rte_eth_rxseg_split — okay so this is a struct from the DPDK Library Functions Manual, and it's the whole blueprint for telling your Rx packets where to get split. Bestie, it's the segment description glow-up 💖

---

✨ SYNOPSIS ✨

#include <rte_ethdev.h>

🎀 Data Fields 🎀

• struct rte_mempool * mp
• uint16_t length
• uint16_t offset
• uint32_t proto_hdr

---

🦋 Detailed Description 🦋

⚠️ Warning — EXPERIMENTAL: this structure may change without prior notice. So like… don't get too attached, it might reinvent itself overnight 😭

A structure used to configure an Rx packet segment to split. It's giving "let's chop this packet up cute and assign each piece a home" 🌸

If the RTE_ETH_RX_OFFLOAD_BUFFER_SPLIT flag is set in the offloads field, the PMD will split the received packets into multiple segments according to the specification in the description array. Slay, the description array is literally the blueprint 👑

• The first network buffer will be allocated from the memory pool specified in the first array element, the second buffer from the pool in the second element, and so on. Matchy-matchy, element by element 💫
• The proto_hdrs in the elements define the split position of received packets. That's the vibe check for where the cut happens ✂️
• The offsets from the segment description elements specify the data offset from the buffer beginning except the first mbuf. The first segment offset is added with RTE_PKTMBUF_HEADROOM. So the first one gets special treatment, and honestly? main character energy 👑
• The lengths in the elements define the maximal data amount being received to each segment. The receiving starts with filling up the first mbuf data buffer up to specified length. If there are data remaining (packet is longer than buffer in the first mbuf) the following data will be pushed to the next segment up to its own length, and so on. It's literally a relay race of bytes 🏃‍♀️
• If the length in the segment description element is zero, the actual buffer size will be deduced from the appropriate memory pool properties. Zero = "you tell me, pool bestie" 🫶
• If there is not enough elements to describe the buffer for entire packet of maximal length, the following parameters will be used for all remaining segments:
  • pool from the last valid element
  • the buffer size from this pool
  • zero offset

(So the leftover segments just inherit the last valid element's whole situation. Recycling, iconic 🧚)

• Length based buffer split:
  • mp, length, offset should be configured.
  • The proto_hdr field must be 0.
• Protocol header based buffer split:
  • mp, offset, proto_hdr should be configured.
  • The length field must be 0.
  • The proto_hdr field in the last segment should be 0.
• When protocol header split is enabled, NIC may receive packets which do not match all the protocol headers within the Rx segments. At this point, NIC will have two possible split behaviors according to matching results, one is exact match, another is longest match. The split result of NIC must belong to one of them. The exact match means NIC only do split when the packets exactly match all the protocol headers in the segments. Otherwise, the whole packet will be put into the last valid mempool. The longest match means NIC will do split until packets mismatch the protocol header in the segments. The rest will be put into the last valid pool. Two completely different coping mechanisms and you gotta know which one your NIC picked 😭

Definition at line 1123 of file rte_ethdev.h.

---

🌈 Field Documentation 🌈

💜 struct rte_mempool* mp

Memory pool to allocate segment from. Home base for that segment 🏡

Definition at line 1124 of file rte_ethdev.h.

💜 uint16_t length

Segment data length, configures split point. This is the "cut here" number ✂️

Definition at line 1125 of file rte_ethdev.h.

💜 uint16_t offset

Data offset from beginning of mbuf data buffer. Where the data actually starts inside the buffer, lowkey important 💀

Definition at line 1126 of file rte_ethdev.h.

💜 uint32_t proto_hdr

proto_hdr defines a bit mask of the protocol sequence as RTE_PTYPE_*. The last RTE_PTYPE* in the mask indicates the split position. So the last one in the mask is the one calling the shots 👑

If one protocol header is defined to split packets into two segments, for non-tunneling packets, the complete protocol sequence should be defined. For tunneling packets, for simplicity, only the tunnel and inner part of complete protocol sequence is required. If several protocol headers are defined to split packets into multi-segments, the repeated parts of adjacent segments should be omitted. Don't repeat yourself, no cap 🙈

Definition at line 1138 of file rte_ethdev.h.

---

🎀 Author 🎀

Generated automatically by Doxygen for DPDK from the source code. Not a human, just a very diligent little robot 🤖✨

---

and that's the whole page bestie! 💖 This gem came to you from the DPDK docs — Version 26.03.0 — auto-generated by Doxygen straight from the source code. Go configure those segments and serve looks 🦋🌸💅