From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 46B2CA034E for ; Wed, 22 Dec 2021 11:01:39 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 3817840DDA; Wed, 22 Dec 2021 11:01:39 +0100 (CET) Received: from mail-ot1-f44.google.com (mail-ot1-f44.google.com [209.85.210.44]) by mails.dpdk.org (Postfix) with ESMTP id A0EA94003C for ; Tue, 21 Dec 2021 12:48:30 +0100 (CET) Received: by mail-ot1-f44.google.com with SMTP id n17-20020a9d64d1000000b00579cf677301so16290711otl.8 for ; Tue, 21 Dec 2021 03:48:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=codilime.com; s=google; h=mime-version:from:date:message-id:subject:to; bh=TqByNQSXarkv8gN6P7ve8cyLrSzGDj7XI/jcgYnx3MQ=; b=FFpmujloDwrQzqQ7R+Nvh/1R4QM+M593L4DjC2am1nd68JKprhwwVPSWUQaHiAPB9W Q3J+mMjqDUMY0hUuVS/mXaxqoz1Jfi4f4FifPCYj9SMyARQ7feYaKKLNzx/hHWbicQCh +dXGXdn0IS9SNsCjnRiHh2lSbpHEYQ9fD2iYjIx44QhtcHtHKsOvH1gRP85VYvwAqMvc wIYizXIzvHeqFP7SddwzwWz2SnLgf3eYmqS0r33/8JXs3Iyuak/WF9zpKZy6oEZ4a/4J eABBxKEmh8DWHgASGVbpUuBfa2Lf2TmuJD62ZoP202TKJRw7Lx6PzR0qd3BbFdxiEXmm Br/w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=TqByNQSXarkv8gN6P7ve8cyLrSzGDj7XI/jcgYnx3MQ=; b=6gCgFcYX4IQL/1Ed7UOPvpfvvuX7dGjutvYavY8Z+LbgkBHgJfhNpPNg+JcEj0hDfp //yDj8oV/Uvo2LvQkBn+gwcoJVcdsM0suSJOlOwMjxF9jxxtwce91oQUBNgtE40VQsPe o/HtweW36dz3+K5q/M4hxNEW1viIu+wgEmDEUWcCYIJHuiSg0UoUthvz8D71uySODzdI mYZLl/y+XpmdNBiPz44y2SnYy09LSm/s1FfmTvinJB+2Fgocey2rvyL3mPaV/HBl75wI kHoh/yNEdB8r6UP/nZ1ziRJkivOnLicUujXpGAvtI7FQjxp7Tphm0/iOSb9gzDJ24mWD Epvw== X-Gm-Message-State: AOAM531SDK3C5UzQHGm35qJE0iW27wD3c3VQ9i2b3x58ZeuAlMkoItQk Yp0k0wcFjsYB5r5keA29Y/wGpmkrUxS1re1Q0WaCVQu5ZuApLiRicjjVuk9SETz9gPz+7DTibkA zNhm35CSdSwnxYmh8xTI/QNU= X-Google-Smtp-Source: ABdhPJwo961l81MLztP7v3yNKHoSPaVMi6QtvGgVqA+Gw7ZL60iGmQUYW1lzoaL2u9kVfOt5QomA/5kA+A9IT0s0X6Q= X-Received: by 2002:a05:6830:1209:: with SMTP id r9mr1073895otp.23.1640087309690; Tue, 21 Dec 2021 03:48:29 -0800 (PST) MIME-Version: 1.0 From: =?UTF-8?Q?Micha=C5=82_Niciejewski?= Date: Tue, 21 Dec 2021 12:48:19 +0100 Message-ID: Subject: Unexpected behavior when using mbuf pool with external buffers To: users@dpdk.org Content-Type: multipart/alternative; boundary="0000000000007f2e7005d3a6959e" X-Mailman-Approved-At: Wed, 22 Dec 2021 11:01:37 +0100 X-BeenThere: users@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK usage discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: users-bounces@dpdk.org --0000000000007f2e7005d3a6959e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, 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: size_t mem_size =3D RTE_ALIGN_CEIL(MBUFS_NUM * QUEUE_NUM * RTE_MBUF_DEFAULT_BUF_SIZE, 4096); auto mem =3D aligned_alloc(4096, mem_size); mlock(mem, mem_size); rte_pktmbuf_extmem ext_mem =3D { .buf_ptr =3D mem, .buf_iova =3D (uintptr_t)mem, .buf_len =3D mem_size, .elt_size =3D RTE_MBUF_DEFAULT_BUF_SIZE, }; if (rte_extmem_register(ext_mem.buf_ptr, ext_mem.buf_len, nullptr, 0, 4096) !=3D 0) throw runtime_error("Failed to register DPDK external memory"); if (rte_dev_dma_map(dev, ext_mem.buf_ptr, ext_mem.buf_iova, ext_mem.buf_len) !=3D 0) throw runtime_error("Failed to DMA map external memory"); mp =3D rte_pktmbuf_pool_create_extbuf("ext_mbuf_pool", MBUFS_NUM * QUEUE_NU= M, 0, 0, RTE_MBUF_DEFAULT_BUF_SIZE, rte_eth_dev_socket_id(0), &ext_mem, 1); if (mp =3D=3D nullptr) throw runtime_error("Failed to create external mbuf pool"); The main loop of the program works like normal l2fwd: it receives packets and sends them to another port. std::vector mbufs(MAX_PKT_BURST); while (true) { auto rx_num =3D rte_eth_rx_burst(0, queue, mbufs.data(), MAX_PKT_BURST)= ; if (!rx_num) continue; // ... auto tx_num =3D rte_eth_tx_burst(1, queue, mbufs.data(), rx_num); rte_pktmbuf_free_bulk(mbufs.data() + tx_num, rx_num - tx_num); } 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: Number of all rx burst calls: 12238365 Number of non-zero rx burst calls: 966834 Avg pkt nb received per rx burst: 0.816879 All received pkts: 9997264 All sent pkts: 9997264 All dropped pkts: 0 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: Queue: 0 Number of rx burst calls: 4449541 Number of non-zero rx burst calls: 1616833 Avg pkt nb received per rx burst: 3.36962 All received pkts: 14993272 All sent pkts: 5827744 All dropped pkts: 9165528 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: Queue: 0 Number of all rx burst calls: 8722385 Number of non-zero rx burst calls: 1447741 Avg pkt nb received per rx burst: 1.14617 All received pkts: 9997316 All sent pkts: 8194416 All dropped pkts: 1802900 So basically it looks like sending too many packets breaks something and starts causing problems when sending fewer packets. I also tried allocating huge pages for mbuf pool instead of memory returned from aligned_alloc: auto mem =3D mmap(0, mem_size, PROT_READ | PROT_WRITE, MAP_PRIVATE | MAP_ANONYMOUS | MAP_HUGETLB, -1, 0); 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. The full code used for testing: https://gist.github.com/tropuq/22625e0e5ac420a8ff5ae072a16f4c06 NIC used: Supermicro AOC-S25G-I2S-O Std Low Profile 25G Dual Port SFP28, based on Intel XXV710 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? Thanks in advance --=20 Micha=C5=82 Niciejewski Junior Software Engineer michal.niciejewski@codilime.com [image: Logo Codilime] [image: Logo Facebook] [image: Logo Linkedin] [image: Logo Twitter] CodiLime Sp. z o.o. - Ltd. company with its registered office in Poland, 02-493 Warsaw, ul. Krancowa 5. Registered by The District Court for the Capital City of Warsaw, XII Commercial Department of the National Court Register. Entered into National Court Register under No. KRS 0000388871. Tax identification number (NIP) 5272657478. Statistical number (REGON) 142974628. --=20 ------------------------------- This document contains material that is=20 confidential in CodiLime Sp. z o.o. DO NOT PRINT. DO NOT COPY. DO NOT=20 DISTRIBUTE. If you are not the intended recipient of this document, be=20 aware that any use, review, retransmission, distribution, reproduction or= =20 any action taken in reliance upon this message is strictly prohibited. If= =20 you received this in error, please contact the sender and help@codilime.com= =20 . Return the paper copy, delete the material from= =20 all computers and storage media. --0000000000007f2e7005d3a6959e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

recently I stumbled upon a problem with mb= uf pool with external buffers. I allocated some memory with aligned_alloc()= , registered it, DMA mapped the memory, and created mbuf pool:

size_= t mem_size =3D RTE_ALIGN_CEIL(MBUFS_NUM * QUEUE_NUM * RTE_MBUF_DEFAULT_BUF_= SIZE, 4096);
auto mem =3D aligned_alloc(4096, mem_size);
mlock(mem, m= em_size);
rte_pktmbuf_extmem ext_mem =3D {
=C2=A0 =C2=A0 .buf_ptr =3D= mem,
=C2=A0 =C2=A0 .buf_iova =3D (uintptr_t)mem,
=C2=A0 =C2=A0 .buf_= len =3D mem_size,
=C2=A0 =C2=A0 .elt_size =3D RTE_MBUF_DEFAULT_BUF_SIZE,=
};

if (rte_extmem_register(ext_mem.buf_ptr, ext_mem.buf_len, nul= lptr, 0, 4096) !=3D 0)
=C2=A0 =C2=A0 throw runtime_error("Failed to= register DPDK external memory");

if (rte_dev_dma_map(dev, ext_= mem.buf_ptr, ext_mem.buf_iova, ext_mem.buf_len) !=3D 0)
=C2=A0 =C2=A0 th= row runtime_error("Failed to DMA map external memory");

mp= =3D 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);
if (mp =3D=3D nullptr)
=C2=A0 =C2=A0 throw runtime_error= ("Failed to create external mbuf pool");

The main loop of = the program works like normal l2fwd: it receives packets and sends them to = another port.

std::vector<rte_mbuf *> mbufs(MAX_PKT_BURST);while (true) {
=C2=A0 =C2=A0 auto rx_num =3D rte_eth_rx_burst(0, queue,= mbufs.data(), MAX_PKT_BURST);
=C2=A0 =C2=A0 if (!rx_num)
=C2=A0 =C2= =A0 =C2=A0 =C2=A0 continue;
=C2=A0 =C2=A0 // ...
=C2=A0 =C2=A0 auto t= x_num =3D rte_eth_tx_burst(1, queue, mbufs.data(), rx_num);
=C2=A0 =C2= =A0 rte_pktmbuf_free_bulk(mbufs.data() + tx_num, rx_num - tx_num);
}
=
Every second, the=C2=A0program prints some info about the packets recei= ved in this second and some stats regarding rte_eth_tx_burst calls. For exa= mple, logs printed while receiving and sending 10mpps:

Number of all= rx burst calls: 12238365
Number of non-zero rx burst calls: 966834
A= vg pkt nb received per rx burst: 0.816879
All received pkts: 9997264
= All sent pkts: 9997264
All dropped pkts: 0

For lower traffic, eve= rything looks fine. But when I start sending more packets some unexpected b= ehavior occurs. When I increase traffic to 15mpps most of the packets are d= ropped on TX:

Queue: 0
Number of rx burst calls: 4449541
Numbe= r of non-zero rx burst calls: 1616833
Avg pkt nb received per rx burst: = 3.36962
All received pkts: 14993272
All sent pkts: 5827744
All dro= pped pkts: 9165528

After that, I checked again the results for 10mpp= s. Even though previously the application didn't have any troubles in m= anaging 10mpps, now it does:

Queue: 0
Number of all rx burst call= s: 8722385
Number of non-zero rx burst calls: 1447741
Avg pkt nb rece= ived per rx burst: 1.14617
All received pkts: 9997316
All sent pkts: = 8194416
All dropped pkts: 1802900

So basically it looks like send= ing too many packets breaks something and starts causing problems when send= ing fewer packets.

I also tried allocating huge pages for mbuf pool = instead of memory returned from aligned_alloc:

auto mem =3D mmap(0, = mem_size, PROT_READ | PROT_WRITE, MAP_PRIVATE | MAP_ANONYMOUS | MAP_HUGETLB= , -1, 0);

And actually, it solved the problems - too big traffic doe= sn't affect lower traffic management. But I still want to know why memo= ry 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 l= ike that.

The full code used for testing: https://gist.github.com/t= ropuq/22625e0e5ac420a8ff5ae072a16f4c06

NIC used: Supermicro AOC-= S25G-I2S-O Std Low Profile 25G Dual Port SFP28, based on Intel XXV710
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?
Thanks in advance

--

Micha=C5=82 Niciejewski

Junior Software = Engineer

= michal= .niciejewski@codilime.com

3D"Logo

3D"Logo= =C2=A03D"Logo<= /a>=C2=A03D"Logo

CodiLime=C2=A0Sp.=C2= =A0z=C2=A0o.o. - Ltd.=C2=A0company with its=C2=A0registered office in=C2=A0= Poland, 02-493 Warsaw, ul.=C2=A0Krancowa=C2=A05.
Registered by=C2=A0The= =C2=A0District Court for=C2=A0the=C2=A0Capital City of=C2=A0Warsaw, XII=C2= =A0Commercial Department of=C2=A0the=C2=A0National Court Register.
Enter= ed into National Court Register under No.=C2=A0KRS=C2=A00000388871. Tax=C2= =A0identification number (NIP) 5272657478. Statistical number (REGON) 14297= 4628.


-------------------------= ------
This documen= t contains material that is confidential in CodiLime Sp. z o.o. DO NOT PRIN= T. 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 strictl= y prohibited. If you received this in error, please contact the sender and = help@codilime.com. Return the paper copy, delete the material from all computers and storag= e media.
--0000000000007f2e7005d3a6959e--