rte_bbdev_op_data(3)

πŸ’– NAME πŸ’–

okay so bestie, this whole page is about rte_bbdev_op_data β€” yes that's the name, and the manual it lives in is the Library Functions Manual, which is exactly as fancy as it sounds πŸ’…


✨ SYNOPSIS ✨

#include <rte_bbdev_op.h>

πŸŽ€ Data Fields πŸŽ€

  • struct rte_mbuf * data
  • uint32_t offset
  • uint32_t length

πŸ¦‹ DETAILED DESCRIPTION πŸ¦‹

it's giving... Data input and output buffer for BBDEV operations ✨ that's the whole vibe.

Definition at line 274 of file rte_bbdev_op.h.


🌸 FIELD DOCUMENTATION 🌸

πŸ’œ struct rte_mbuf* data

The mbuf data structure representing the data for BBDEV operation. literally the main character of this struct 🫢

This mbuf pointer can point to one Code Block (CB) data buffer or multiple CBs contiguously located next to each other. And bestie, a Transport Block (TB) represents a whole piece of data that is divided into one or more CBs. Maximum number of CBs can be contained in one TB is defined by RTE_BBDEV_(TURBO/LDPC)_MAX_CODE_BLOCKS.

An mbuf data structure cannot represent more than one TB, no cap. The smallest piece of data that can be contained in one mbuf is one CB. So an mbuf can include:

  • one contiguous CB,
  • a subset of contiguous CBs that are belonging to one TB,
  • or all contiguous CBs that are belonging to one TB.

If a BBDEV PMD supports the extended capability "Scatter-Gather", then it is capable of collecting (gathering) non-contiguous (scattered) data from multiple locations in the memory 😭 iconic honestly. This capability is reported by the capability flags:

  • RTE_BBDEV_(TURBO/LDPC)_ENC_SCATTER_GATHER and
  • RTE_BBDEV_(TURBO/LDPC)_DEC_SCATTER_GATHER.

Only if a BBDEV PMD supports this feature, chained mbuf data structures are accepted ⭐ A chained mbuf can represent one non-contiguous CB or multiple non-contiguous CBs. If BBDEV PMD does not support this feature, it will assume inbound mbuf data contains one segment.

The output mbuf data though is always one segment, even if the input was a chained mbuf. periodt. πŸ’€

Definition at line 304 of file rte_bbdev_op.h.


πŸ“ uint32_t offset

The starting point of the BBDEV (encode/decode) operation, in bytes.

BBDEV starts to read data past this offset. In case of chained mbuf, this offset applies only to the first mbuf segment.

Definition at line 312 of file rte_bbdev_op.h.


🌈 uint32_t length

The total data length to be processed in one operation, in bytes.

So like, in case the mbuf data is representing one CB, this is the length of the CB undergoing the operation. If it's for multiple CBs, this is the total length of those CBs undergoing the operation. If it is for one TB, this is the total length of the TB under operation. slay, it scales 😌

In case of chained mbuf, this data length includes the lengths of the "scattered" data segments undergoing the operation.

Definition at line 325 of file rte_bbdev_op.h.


πŸ‘‘ AUTHOR πŸ‘‘

Generated automatically by Doxygen for DPDK from the source code. not a human wrote this, it's the machine's finest work πŸ€–βœ¨


and that's the whole page bestie!! this lovely thing shipped in DPDK Version 25.11.3, it's the rte_bbdev_op_data(3) page from the Library Functions Manual, and yes it's auto-generated Doxygen energy from top to bottom. go forth and gather those scattered CBs πŸ§šπŸ’–βœ¨

πŸ“¦ where this page comes from