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

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

[Mauricio Vásquez]

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

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

[Burakov, Anatoly]

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 

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

[Mauricio Vásquez]

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
>