From: Dmitry Kozlyuk <dmitry.kozliuk@gmail.com>
To: Jakob Wieckowski <Jakob.Wieckowski@gmx.net>
Cc: users@dpdk.org
Subject: Re: dynamic and variable mbuf size
Date: Fri, 15 Mar 2024 12:38:24 +0300 [thread overview]
Message-ID: <20240315123824.1f59a78f@sovereign> (raw)
In-Reply-To: <trinity-38c92680-de4b-46fb-bcfd-db0e81179fbd-1710488835400@3c-app-gmx-bap18>
2024-03-15 08:47 (UTC+0100), Jakob Wieckowski:
> Hello DPDK Users,
>
> I have a question regarding the size of mbufs.
> The mbuf are contained in the mempol and the mempool is a fixed size object.
>
> Could the mbuf be implemented dynamically with a variable size in the
> mempool area ?
>
> In the header of the mbuf you could specify the size of the payload data
> and thus could expand the size of the mbufs.
>
> From my understanding, you just have to keep an eye on the mempool memory
> size so that it doesn't go beyond the limit of the allocated area.
>
> Would this be generally possible?
Hi,
If mbufs could be allocated of any size,
mempool would be a general-purpose allocator,
but there is a tradeoff between generality and performance,
and rte_mempool pursuits the latter.
The size of an mbuf data may only be adjusted,
but only up to the size specified at mempool creation.
There are solutions for some use cases:
- using multiple mempools for objects of different size
- some NICs can split packets allocating segments from different mempools
- mbufs can be chained
- rte_pktmbuf_attach_extbuf() + custom allocator
- "memarea" proposed library [1] (looks very similar to what you describe)
What is you usage scenario?
[1]: http://inbox.dpdk.org/dev/20230720092254.54157-1-fengchengwen@huawei.com/
prev parent reply other threads:[~2024-03-15 9:38 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-03-15 7:47 Jakob Wieckowski
2024-03-15 9:38 ` Dmitry Kozlyuk [this message]
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=20240315123824.1f59a78f@sovereign \
--to=dmitry.kozliuk@gmail.com \
--cc=Jakob.Wieckowski@gmx.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).