On 03-Oct-18 1:39 PM, Darek Stojaczyk wrote:
So far each process in MP used to have a separate container
and relied on the primary process to register all memsegs.
Mapping external memory via rte_vfio_container_dma_map()
in secondary processes was broken, because the default
(process-local) container had no groups bound. There was
even no way to bind any groups to it, because the container
fd was deeply encapsulated within EAL.
This patch introduces a new SOCKET_REQ_DEFAULT_CONTAINER
message type for MP synchronization, makes all processes
within a MP party use a single default container, and hence
fixes rte_vfio_container_dma_map() for secondary processes.
From what I checked this behavior was always the same, but
started to be invalid/insufficient once mapping external
memory was allowed.
Fixes: 73a639085938 ("vfio: allow to map other memory regions")
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
While here, fix up the comment on rte_vfio_get_container_fd().
This function always opens a new container, never reuses
an old one.
Signed-off-by: Darek Stojaczyk <[email protected]>
---
This makes things a bit funky when we consider external memory support.
The same address space may or may not be mapped into the process, so we
may or may not need to map things for DMA depending on whether we're
mapping shared memory for DMA, or not.
The previous behavior may be counter-intuitive, but it's IMO the correct
one - each process has its own container and performs its own DMA mappings.
--
Thanks,
Anatoly
