From: "Morten Brørup" <mb@smartsharesystems.com>
To: "Anatoly Burakov" <anatoly.burakov@intel.com>
Cc: "Olivier Matz" <olivier.matz@6wind.com>,
"Andrew Rybchenko" <arybchenko@solarflare.com>, <dev@dpdk.org>
Subject: [dpdk-dev] The type string in the malloc library is unused
Date: Fri, 13 Sep 2019 15:32:25 +0200 [thread overview]
Message-ID: <98CBD80474FA8B44BF855DF32C47DC35B42A99@smartserver.smartshare.dk> (raw)
Hi Anatoly,
The functions in the DPDK malloc library takes a "type" parameter (a string, supposedly for debug purposes), but the underlying malloc_heap functions (which take the same string parameter) don't store or use this string for anything.
Is the intention to implement this sometime in the future, or should it be considered for removal?
I was originally looking for a function for my primary process to allocate a block of named memory in the huge-page area, so my secondary process could look it up and use it. And I would simply use a unique type string for this, and add an rte_malloc_lookup function. However, that obviously doesn't work when the type parameter is not used during allocation.
The simplest workaround I can come up with is using a named mempool with a single element, where this element is my memory block. I get an element from this mempool to find the address of my memory block, store the address, and put the element back in the mempool, so the secondary process can get the address the same way, i.e. by getting and putting the element back into the mempool while storing the element's address underway.
Any better ideas?
Med venlig hilsen / kind regards
Morten Brørup
CTO
SmartShare Systems A/S
Tonsbakken 16-18
DK-2740 Skovlunde
Denmark
Office +45 70 20 00 93
Direct +45 89 93 50 22
Mobile +45 25 40 82 12
mb@smartsharesystems.com <mailto:mb@smartsharesystems.com>
www.smartsharesystems.com <https://www.smartsharesystems.com/>
next reply other threads:[~2019-09-13 13:32 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-09-13 13:32 Morten Brørup [this message]
2019-09-13 19:38 ` Alexander Pshenichnikov
2019-09-14 7:06 ` Morten Brørup
[not found] ` <CAOaVG17_bhBOfJdvHZOzoVO3t7CXCZCa7f=_Q=_Pi5jgnY3GzA@mail.gmail.com>
2019-09-14 8:29 ` Morten Brørup
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=98CBD80474FA8B44BF855DF32C47DC35B42A99@smartserver.smartshare.dk \
--to=mb@smartsharesystems.com \
--cc=anatoly.burakov@intel.com \
--cc=arybchenko@solarflare.com \
--cc=dev@dpdk.org \
--cc=olivier.matz@6wind.com \
/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).