2016-06-10 09:05, Burakov, Anatoly: > 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?
Everything is possible :) Maybe you just need to add an API to add some memory segments. Other question: why is it so important to register these memory segments in EAL? I think they just need to be known by the ivshmem driver which map some objects on top. > > 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 :) We can keep supporting 2M pages by having a command line option, instead of the #ifdef RTE_EAL_SINGLE_FILE_SEGMENTS. But as I said, it is not the top priority to remove this hack.
