</title> <image href="GUID-4119C4BD-ABBF-524B-B649-0F39EF58A7FB_d0e139868_href.png" placement="inline"/></fig> <p>For more information about these classes, see the following table and the reference documentation: </p> <table id="GUID-BC77F10C-E6C7-5447-A61F-63671B5F0FEC"><tgroup cols="2"><colspec colname="col0"/><colspec colname="col1"/><thead><row><entry>Class</entry> <entry>Description</entry> </row> </thead> <tbody><row><entry><p> <xref href="GUID-E0ADB108-D3B2-3670-907D-2AE595BECE3F.dita"><apiname>RMBuf</apiname></xref>  </p> </entry> <entry><p>Representation of a shared buffer designed to carry packets within the Comms Data Plane. </p> <p>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. </p> <p>Part of the API is located in the parent class : <xref href="GUID-4FB33BFE-DCF7-3B77-A447-F9C049DF86CB.dita"><apiname>RCommsBuf</apiname></xref>. </p> </entry> </row> <row><entry><p> <xref href="GUID-F024208C-ED19-3301-85C1-53F397C9910F.dita"><apiname>RMBufChain</apiname></xref>  </p> </entry> <entry><p>Chain of <codeph>RMBuf</codeph> objects. </p> <p>Part of the API is located in the parent class : <xref href="GUID-107ADE6D-7AFF-3B07-9606-BCA33A3B63EF.dita"><apiname>RCommsBufChain</apiname></xref>. </p> </entry> </row> </tbody> </tgroup> </table> </section> <section id="GUID-5EBCD46C-5E07-5DB1-90D9-6A5CA3E36C0B"><title> Buffer layout</title> <p>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. </p> <fig id="GUID-6598A097-0453-5499-9507-2419DF73C023"><title>

          </title> <image href="GUID-9FB3502C-B3DF-5FBC-972D-0D476D661954_d0e139955_href.png" placement="inline"/></fig> <p>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. </p> <p>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. </p> <p>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): </p> <fig id="GUID-17B63072-ED95-5626-88D0-80AF8790B5CE"><title>

          </title> <image href="GUID-32D39AB1-D1B0-5F44-8226-0777B8010C7D_d0e139970_href.png" placement="inline"/></fig> <p>For simplified code corresponding to this diagram, see <xref href="GUID-FE3825C5-BDEE-5F18-9FFD-2E794E618FEC.dita">Data Access Example</xref>. </p> </section> </conbody><related-links><link href="GUID-55E4D84B-1B90-5BA4-9CE0-6D26EA208F13.dita"><linktext>Overview</linktext> </link> <link href="GUID-65C49B47-6C63-536E-9B31-1FFA518A63F1.dita"><linktext>Shared Buffers</linktext> </link> <link href="GUID-A467E933-C4B4-5518-96D6-471E44B216B3.dita"><linktext>Advanced Pond