From: "Mauricio Vásquez" <mauricio.vasquezbernal@studenti.polito.it>
To: "Burakov, Anatoly" <anatoly.burakov@intel.com>
Cc: "dev@dpdk.org" <dev@dpdk.org>
Subject: Re: [dpdk-dev] Why rte_eal_ivshmem_obj_initd() does not add memory pools to rte_mempool_tailq list?
Date: Fri, 16 Oct 2015 15:16:04 +0200 [thread overview]
Message-ID: <CAPwdgqh5u0ff=+MYV5cLsbvtqPQ3C0dZ2Pb2duHQuoYzD=0KDQ@mail.gmail.com> (raw)
In-Reply-To: <C6ECDF3AB251BE4894318F4E4512369780D532ED@IRSMSX109.ger.corp.intel.com>
Hi Anatoly,
Thank you very much for your answer, it clarifies it for me. I absolutely
agree with you that adding mempools support should not be implemented until
a solution for mempool cache corruption is found.
Mauricio,
On 16 October 2015 at 15:00, Burakov, Anatoly <anatoly.burakov@intel.com>
wrote:
> Hi Mauricio
>
> > Dear DPDK community,
> >
> > Some time ago I was trying to map a memory pool into a guest using
> > IVSHMEM as described here:
> >
> > http://comments.gmane.org/gmane.comp.networking.dpdk.devel/17779
> >
> > After some time I decided to review the code of eal_ivshmem.c, I noticed
> > that in the function rte_eal_ivshmem_obj_init the rings are added to the
> > rte_ring_tailq list, but for memory pools there is not a similar
> procedure.
> > My question is why it does not exist such procedure? Is there any reason
> or
> > is it just missing?
> >
> > If it is just missing I could propose a implementation for it,
> >
> > Thank you very much for your attention,
> >
> > Mauricio Vásquez
>
> Sharing mempools over IVSHMEM is not supported because all sorts of
> strange things start to happen when you consider that mempool caches (which
> are not thread safe) are part of the picture. The only way to even work
> with mempools over IVSHMEM without things horribly breaking would be to
> either always watch your coremasks (which is prone to user error) or
> disable mempool caches (which slows things down). This is the reason
> sharing mempools over IVSHMEM was never supported.
>
> Technically, there is nothing stopping you to implement it yourself - all
> you have to do is to add a wrapper that looks for their memzones (like we
> have for rings), and add an auto-discovery mechanism to the EAL IVSHMEM
> code (again, like we have for rings). However, unless things I mentioned
> aren't a problem anymore for whatever reason, I would be very reluctant to
> ack a patch adding mempools support to IVSHMEM code.
>
> Thanks,
> Anatoly
>
prev parent reply other threads:[~2015-10-16 13:16 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-10-15 16:45 Mauricio Vásquez
2015-10-16 13:00 ` Burakov, Anatoly
2015-10-16 13:16 ` Mauricio Vásquez [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='CAPwdgqh5u0ff=+MYV5cLsbvtqPQ3C0dZ2Pb2duHQuoYzD=0KDQ@mail.gmail.com' \
--to=mauricio.vasquezbernal@studenti.polito.it \
--cc=anatoly.burakov@intel.com \
--cc=dev@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).