DPDK usage discussions
 help / color / mirror / Atom feed
From: Filip Matracki <filip.matracki@pico.net>
To: "users@dpdk.org" <users@dpdk.org>
Subject: Strategy for contiguous packet payload processing using DPDK mbufs
Date: Wed, 27 Jul 2022 15:03:51 +0000	[thread overview]
Message-ID: <MW3PR22MB21081B7AE10ECAC571211E18E0979@MW3PR22MB2108.namprd22.prod.outlook.com> (raw)


[-- Attachment #1.1: Type: text/plain, Size: 3115 bytes --]

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.
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 mbuf documentation<https://doc.dpdk.org/guides/_images/mbuf2.svg>:
[enter image description here]<https://i.stack.imgur.com/3mlE4.png>
This leads us the following problems:
*         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!
*         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.

Considering the above,  my questions are as follows:
1.      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?
2.      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?

________________________________
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.

[-- Attachment #1.2: Type: text/html, Size: 12061 bytes --]

[-- Attachment #2: image001.png --]
[-- Type: image/png, Size: 130435 bytes --]

             reply	other threads:[~2022-07-28  9:03 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-07-27 15:03 Filip Matracki [this message]
2022-07-28  9:21 ` Pawel Wodkowski

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=MW3PR22MB21081B7AE10ECAC571211E18E0979@MW3PR22MB2108.namprd22.prod.outlook.com \
    --to=filip.matracki@pico.net \
    --cc=users@dpdk.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).