<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"> <head> <meta http-equiv="Content-Type" content="text/html; charset=us-ascii"> <meta name="Generator" content="Microsoft Word 15 (filtered medium)"> <style></style> </head> <body lang="EN-GB" link="#0563C1" vlink="#954F72" style="word-wrap:break-word"> <div class="WordSection1"> We have a DPDK application that only calls rte_eth_rx_burst() (we do not transmit packets) and it must process the payload very quickly. The payload of a single network packet MUST be in contiguous memory.<o:p></o:p> The DPDK API is optimized around having memory pools of fixed-size mbufs in memory pools. If a packet is received on the DPDK port that is larger than the mbuf size, but smaller than the max MTU then it will be segmented according to the figure in the <a href="https://doc.dpdk.org/guides/_images/mbuf2.svg">mbuf documentation</a>:<o:p></o:p> <a href="https://i.stack.imgur.com/3mlE4.png"><img border="0" width="707" height="348" style="width:7.3645in;height:3.625in" id="Picture_x0020_1" src="cid:image001.png@01D8A1D9.DC86DA30" alt="enter image description here"></a><o:p></o:p> This leads us the following problems:<o:p></o:p> <![if !supportLists]>· <![endif]>If we configure the memory pool to store large packets (for example max MTU size) then we will always store the payload in contiguous memory, but we will waste huge amounts memory in the case we receive traffic containing small packets. Imagine that our mbuf size is 9216 bytes, but we are receiving mostly packets of size 100-300 bytes. We are wasting memory by a factor of 90!<o:p></o:p> <![if !supportLists]>· <![endif]>If we reduce the size of mbufs, to let's say 512 bytes, then we need special handling of those segments to store the payload in contiguous memory. Special handling and copying of segments hurt our performance, so it should be limited.<o:p></o:p> <o:p> </o:p> Considering the above, my questions are as follows:<o:p></o:p> <![if !supportLists]>1. <![endif]>What strategy is recommended for a DPDK application that needs to process the payload of network packets in contiguous memory? With both small (100-300 bytes) and large (9216) packets, without wasting huge amounts of memory with 9K-sized mbuf pools? Is copying segmented jumbo frames into a larger max_mtu mbuf the only option?<o:p></o:p> <![if !supportLists]>2. <![endif]>Some frameworks and drivers allow decoupling the RX descriptors (mbuf) from the payload, such that payloads are stored contiguously. This does not seem to be possible in the DPDK framework for segmented packets, since mbufs are stored right next to their payload in memory?<o:p></o:p> <o:p> </o:p> </div> <hr> Pico Quantitative Trading LLC ("PQT"). This e-mail (including any attachments) is intended only for use by the addressee(s) named above, and may contain confidential, proprietary or legally privileged information. If you are not the intended recipient of this e-mail, any review, use, disclosure, dissemination, distribution, printing or copying of this e-mail or any attachment is strictly prohibited. If you have received this e-mail in error, please notify Pico immediately by return e-mail and permanently delete the original from your system and any hard copy printout thereof. E-mails are not encrypted and cannot be guaranteed to be secure or error-free and, as with all Internet communications, information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. Accordingly, Pico accepts no liability for any errors or omissions in the content contained herein. In compliance with applicable laws, rules and regulations and/or at its discretion, Pico may review and archive incoming and outgoing e-mail communications, copies of which may be produced at the request of regulators. </body> </html>