Comms Buffers (MBuf) ans Comms Chains
This topic describes Comms buffers (MBuf) and Comms chains.
APIs
The following diagram is a partial representation of the class hierarchy for RMBuf.
For more information about these classes, see the following table and the reference documentation:
| Class | Description |
|---|---|
Representation of a shared buffer designed to carry packets within the Comms Data Plane. It includes Comms metadata (such as the offset, the size and the type of the data within the buffer) and links to the next buffer in the buffer chain. Part of the API is located in the parent class : RCommsBuf. |
|
Chain of RMBuf objects. Part of the API is located in the parent class : RCommsBufChain. |
Buffer layout
The following diagram shows the contents of a Comms buffer and the location of the metadata. The metadata is at the end so that the device drivers can ignore the metadata and write their payload at the beginning of the buffer.
The metadata contains information about the payload: its length and offset, the type of data it contains, and references to the pond and the pool where the buffer's memory is located. Whenever you perform an operation on an MBuf, the chain or the pond update the metadata.
The offset at the beginning of the buffer is an important optimisation when sending data downwards through the Comms Data Plane. Leaving enough space for the protocol headers enables Comms Framework components to prepend their data to the payload without requesting a new MBuf and its addition to the front of the buffer chain. Therefore, you should always define a pool according to the biggest packet that the bottom of the stack may receive : for example, 1518 bytes for Ethernet packets.
The following diagram is an example illustrating how the Comms Data Plane removes the headers from the payload (on the way up the stack) or prepend header to the payload (on the way down):
For simplified code corresponding to this diagram, see Data Access Example.