[dpdk-dev] [PATCH] dropping librte_ivshmem - was log: deprecate history dump

Burakov, Anatoly anatoly.burakov at intel.com
Fri Jun 10 11:05:51 CEST 2016


Hi Thomas,

Just a few notes:

> 3/ The automatic mapped allocation of DPDK objects in the guest.
> It should not be done in EAL.
> An ivshmem driver would be called by rte_eal_dev_init.
> It would check where are the shared DPDK structures, as currently done with
> the IVSHMEM_MAGIC (0x0BADC0DE), and do the appropriate allocations.
> Thus only the driver would depend on ring and mempool.

The problem here is IVSHMEM doesn't allocate the memory from DPDK, it allocates new memory segments by mapping a PCI device. I.e. it doesn't do mallocs, it modifies mem_config and adds memory to DPDK. Can that be done from within a PMD?

> 
> The last step of the ivshmem cleanup will be to remove the memory hack
> RTE_EAL_SINGLE_FILE_SEGMENTS. Then CONFIG_RTE_LIBRTE_IVSHMEM
> could be removed.

The reason for that hack is that we often need to map several hugepages, and some of those pages could be 2M in size. If you're sharing 1G worth of contiguous memory backed by 2M pages, that's 512 files in the command line in vanilla DPDK, but can be made into one with RTE_EAL_SINGLE_FILE_SEGMENTS, so that QEMU command-line doesn't get overly long.

So removing this hack, while definitely desired, will adversely affect some use cases, such as using IVSHMEM on platforms where 1G pages aren't supported. Whether we want to go with the effort of supporting those is of course an open question - I personally don't have any data on IVSHMEM userbase. Maybe Kevin/other OVS devs could help me out here :)

Thanks,
Anatoly


More information about the dev mailing list