<div dir="ltr">Hi,<br><br>recently I stumbled upon a problem with mbuf pool with external buffers. I allocated some memory with aligned_alloc(), registered it, DMA mapped the memory, and created mbuf pool:<br><br>size_t mem_size = RTE_ALIGN_CEIL(MBUFS_NUM * QUEUE_NUM * RTE_MBUF_DEFAULT_BUF_SIZE, 4096);<br>auto mem = aligned_alloc(4096, mem_size);<br>mlock(mem, mem_size);<br>rte_pktmbuf_extmem ext_mem = {<br>    .buf_ptr = mem,<br>    .buf_iova = (uintptr_t)mem,<br>    .buf_len = mem_size,<br>    .elt_size = RTE_MBUF_DEFAULT_BUF_SIZE,<br>};<br><br>if (rte_extmem_register(ext_mem.buf_ptr, ext_mem.buf_len, nullptr, 0, 4096) != 0)<br>    throw runtime_error("Failed to register DPDK external memory");<br><br>if (rte_dev_dma_map(dev, ext_mem.buf_ptr, ext_mem.buf_iova, ext_mem.buf_len) != 0)<br>    throw runtime_error("Failed to DMA map external memory");<br><br>mp = rte_pktmbuf_pool_create_extbuf("ext_mbuf_pool", MBUFS_NUM * QUEUE_NUM, 0, 0, RTE_MBUF_DEFAULT_BUF_SIZE, rte_eth_dev_socket_id(0), &ext_mem, 1);<br>if (mp == nullptr)<br>    throw runtime_error("Failed to create external mbuf pool");<br><br>The main loop of the program works like normal l2fwd: it receives packets and sends them to another port.<br><br>std::vector<rte_mbuf *> mbufs(MAX_PKT_BURST);<br>while (true) {<br>    auto rx_num = rte_eth_rx_burst(0, queue, mbufs.data(), MAX_PKT_BURST);<br>    if (!rx_num)<br>        continue;<br>    // ...<br>    auto tx_num = rte_eth_tx_burst(1, queue, mbufs.data(), rx_num);<br>    rte_pktmbuf_free_bulk(mbufs.data() + tx_num, rx_num - tx_num);<br>}<br><br>Every second, the program prints some info about the packets received in this second and some stats regarding rte_eth_tx_burst calls. For example, logs printed while receiving and sending 10mpps:<br><br>Number of all rx burst calls: 12238365<br>Number of non-zero rx burst calls: 966834<br>Avg pkt nb received per rx burst: 0.816879<br>All received pkts: 9997264<br>All sent pkts: 9997264<br>All dropped pkts: 0<br><br>For lower traffic, everything looks fine. But when I start sending more packets some unexpected behavior occurs. When I increase traffic to 15mpps most of the packets are dropped on TX:<br><br>Queue: 0<br>Number of rx burst calls: 4449541<br>Number of non-zero rx burst calls: 1616833<br>Avg pkt nb received per rx burst: 3.36962<br>All received pkts: 14993272<br>All sent pkts: 5827744<br>All dropped pkts: 9165528<br><br>After that, I checked again the results for 10mpps. Even though previously the application didn't have any troubles in managing 10mpps, now it does:<br><br>Queue: 0<br>Number of all rx burst calls: 8722385<br>Number of non-zero rx burst calls: 1447741<br>Avg pkt nb received per rx burst: 1.14617<br>All received pkts: 9997316<br>All sent pkts: 8194416<br>All dropped pkts: 1802900<br><br>So basically it looks like sending too many packets breaks something and starts causing problems when sending fewer packets.<br><br>I also tried allocating huge pages for mbuf pool instead of memory returned from aligned_alloc:<br><br>auto mem = mmap(0, mem_size, PROT_READ | PROT_WRITE, MAP_PRIVATE | MAP_ANONYMOUS | MAP_HUGETLB, -1, 0);<br><br>And actually, it solved the problems - too big traffic doesn't affect lower traffic management. But I still want to know why memory allocated using aligned_alloc causes problems because in the place where I want to use mbuf pools with external buffers huge pages cannot be used like that.<br><br>The full code used for testing: <a href="https://gist.github.com/tropuq/22625e0e5ac420a8ff5ae072a16f4c06" target="_blank">https://gist.github.com/tropuq/22625e0e5ac420a8ff5ae072a16f4c06</a><br><br>NIC used: Supermicro AOC-S25G-I2S-O Std Low Profile 25G Dual Port SFP28, based on Intel XXV710<br><br>Did anyone have similar issues or know what could cause such behavior? Is this allocation of the mbuf pool correct or am I missing something?<br><br>Thanks in advance<br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><table style="border-spacing:0px;border-collapse:collapse;color:rgb(51,51,51);font-family:"Helvetica Neue",Helvetica,Arial,sans-serif;font-size:14px"><tbody><tr><td style="padding:0px"><p style="margin:0px;font-family:"Helvetica Neue",Helvetica,Arial,sans-serif;font-weight:bold;line-height:1.2em">Michał Niciejewski</p></td></tr><tr><td style="padding:0px"><p style="margin:0px;font-family:"Helvetica Neue",Helvetica,Arial,sans-serif;font-size:12px;line-height:1.2em">Junior Software Engineer</p></td></tr><tr><td style="padding:0px"><p style="margin:0px;font-family:"Helvetica Neue",Helvetica,Arial,sans-serif;font-size:12px;padding-top:5px;line-height:1.2em"></p></td></tr><tr><td style="padding:0px"><p style="margin:0px;font-family:"Helvetica Neue",Helvetica,Arial,sans-serif;color:rgb(0,0,0);font-size:12px;line-height:1.2em"><a href="mailto:michal.niciejewski@codilime.com" target="_blank">michal.niciejewski@codilime.com</a></p></td></tr><tr style="padding-bottom:10px"><td style="padding:0px"><a href="http://www.codilime.com/?utm_source=Stopka&utm_medium=Email&utm_campaign=Stopka" style="background-color:transparent;color:rgb(51,122,183)" target="_blank"><img src="https://img.codilime.com/codilime_460.png" alt="Logo Codilime" style="border:0px;vertical-align:middle;width:138px;padding-top:20px;margin-bottom:10px"></a></td></tr><tr><td style="padding:0px"><p style="margin:0px 0px 10px"><a href="https://www.facebook.com/codilime/" style="background-color:transparent;color:rgb(51,122,183)" target="_blank"><img src="https://img.codilime.com/facebook_104.png" alt="Logo Facebook" style="border:0px;vertical-align:middle;width:26px;height:26px;margin-right:7px"></a> <a href="https://www.linkedin.com/company/codilime" style="background-color:transparent;color:rgb(51,122,183)" target="_blank"><img src="https://img.codilime.com/linkedin_104.png" alt="Logo Linkedin" style="border:0px;vertical-align:middle;width:26px;height:26px;margin-right:7px"></a> <a href="https://twitter.com/codilime" style="background-color:transparent;color:rgb(51,122,183)" target="_blank"><img src="https://img.codilime.com/twitter_104.png" alt="Logo Twitter" style="border:0px;vertical-align:middle;width:26px;height:26px"></a></p></td></tr><tr><td style="padding:0px"><p style="margin:0px;line-height:1.2em;font-size:7.5pt;font-family:Calibri,sans-serif;color:rgb(204,204,204)">CodiLime Sp. z o.o. - Ltd. company with its registered office in Poland, 02-493 Warsaw, ul. Krancowa 5.<br>Registered by The District Court for the Capital City of Warsaw, XII Commercial Department of the National Court Register.<br>Entered into National Court Register under No. KRS 0000388871. Tax identification number (NIP) 5272657478. Statistical number (REGON) 142974628.</p></td></tr></tbody></table></div></div></div>

<br>
<p style="font-family:Calibri;font-size:1.3em;margin:0cm 0cm 0.0001pt"><img></p><span style="font-family:Calibri,sans-serif;font-size:1.3em;color:rgb(118,247,3)"><font size="1"><div><span style="color:rgb(204,204,204);font-size:9px;background-color:rgb(255,255,255)">------------------------------<wbr>-</span></div></font></span><div style="font-family:Arial,Helvetica,sans-serif"><span style="color:rgb(204,204,204);font-family:Calibri,sans-serif;background-color:rgb(255,255,255)"><font size="1">This document contains material that is confidential in CodiLime Sp. z o.o. DO NOT PRINT. DO NOT COPY. DO NOT DISTRIBUTE. If you are not the intended recipient of this document, be aware that any use, review, retransmission, distribution, reproduction or any action taken in reliance upon this message is strictly prohibited. If you received this in error, please contact the sender and <a href="mailto:help@codilime.com" target="_blank">help@codilime.com</a>. Return the paper copy, delete the material from all computers and storage media.</font></span></div>