DPDK patches and discussions
 help / color / mirror / Atom feed
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
>

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