Comms Buffers (MBuf) ans Comms Chains

APIs

The following diagram is a partial representation of the class hierarchy for RMBuf .

Figure 1. Comms buffer

For more information about these classes, see the following table and the reference documentation:

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.

Figure 2. Comms buffer contents

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):

Figure 3. Header manipulation example

For simplified code corresponding to this diagram, see Data Access Example .