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 >