[dpdk-dev] Why rte_eal_ivshmem_obj_initd() does not add memory pools to rte_mempool_tailq list?

Mauricio Vásquez mauricio.vasquezbernal at studenti.polito.it
Fri Oct 16 15:16:04 CEST 2015


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 at 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
>


More information about the dev mailing list