From: Thomas Monjalon <thomas.monjalon@6wind.com>
To: Luca Boccassi <lboccass@brocade.com>
Cc: dev@dpdk.org
Subject: Re: [dpdk-dev] DPDK (and rte_*alloc family) friendly Valgrind
Date: Mon, 15 Feb 2016 10:16:03 +0100 [thread overview]
Message-ID: <1721773.5Epq0nJNZu@xps13> (raw)
In-Reply-To: <1455366618.3599.35.camel@brocade.com>
2016-02-13 12:30, Luca Boccassi:
> On Thu, 2016-02-11 at 08:34 +0100, Thomas Monjalon wrote:
> > 2016-02-10 22:54, Luca Boccassi:
> > I created a set of patches for Valgrind that add support for the
> > > rte_*alloc family of functions. We use it for memcheck (I added support
> > > for other all the other Valgrind tools like cachegrind as well, but it's
> > > less tested), and find it extremely useful, since the vanilla version
> > > cannot intercept and report leaks cause by rte_*alloc functions from
> > > librte_malloc.
> >
> > Thank you Luca.
> > I think it deserves to be visible in the DPDK doc.
> > What about adding some explanations in
> > https://urldefense.proofpoint.com/v2/url?u=http-3A__dpdk.org_doc_guides_prog-5Fguide_profile-5Fapp.html&d=CwICAg&c=IL_XqQWOjubgfqINi2jTzg&r=QTEM8ICX7t_SLgWP3qPWtKiwKMps487LPWQx-B9AqIc&m=QXy2HY_6FCRpB2dqb0AfDLoTIJ2MpHaKS_Bd5WKYgMQ&s=d4OWq_1QIlrYTxkCHIsQqn7p0887PWo4RaYa7PZeeII&e=
> > or
> > https://urldefense.proofpoint.com/v2/url?u=http-3A__dpdk.org_doc_guides_prog-5Fguide_env-5Fabstraction-5Flayer.html-23malloc&d=CwICAg&c=IL_XqQWOjubgfqINi2jTzg&r=QTEM8ICX7t_SLgWP3qPWtKiwKMps487LPWQx-B9AqIc&m=QXy2HY_6FCRpB2dqb0AfDLoTIJ2MpHaKS_Bd5WKYgMQ&s=J36uf3GxS8AuoM2eQje4VTbXuF4WLmxGKIXM3RslaOA&e=
> > ?
>
> Hi Thomas,
>
> Thanks, anything I could help with for that to happen?
Yes, the documentation is in the git tree.
If you have time, it would be nice to send a patch on this list to
point your patches and explain how it works (below notes can be included).
The guide for doc contribution is http://dpdk.org/doc/guides/contributing/documentation.html
> Also, a few words about the actual implementation.
>
> Valgrind re-implements the whole *alloc and friends internally. There is
> a common framework shared between the various tools, and each builds on
> top of it.
>
> What I've done is to map the various rte_*alloc/free functions on top of
> Valgrind's implementation of posix_memalign/free. This was done in order
> to respect the cache alignment parameter of rte_malloc and friends. I've
> tested to make sure that this works correctly, as we rely heavily upon
> it.
>
> I have not, however, implemented support for NUMA sockets. There is no
> such concept inside Valgrind's framework at the moment, so it would be a
> monumental task. The NUMA socket parameter will simply be ignored. I do
> not believe it would be very useful to implement support for it, as it
> doesn't add much. For the purpose of memory leaks detection, I don't
> think it matters much on which socket a memory block is allocated.
>
> This might have an effect on cachegrind though, so it's worth noting and
> bearing it in mind when using cachegrind rather than memcheck.
>
> I've added a note on Github.
Thanks
prev parent reply other threads:[~2016-02-15 9:17 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-02-10 22:54 Luca Boccassi
2016-02-11 7:34 ` Thomas Monjalon
2016-02-13 6:47 ` Matthew Hall
2016-02-13 12:15 ` Luca Boccassi
2016-02-13 12:30 ` Luca Boccassi
2016-02-13 19:59 ` Matthew Hall
2016-02-15 9:16 ` Thomas Monjalon [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=1721773.5Epq0nJNZu@xps13 \
--to=thomas.monjalon@6wind.com \
--cc=dev@dpdk.org \
--cc=lboccass@brocade.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).