Re: [dpdk-dev] Windows Support Plan

["Burakov, Anatoly" <anatoly.burakov@intel.com>]

On 02-Feb-20 8:37 PM, Dmitry Kozliuk wrote:
> Hi everyone!
> 

Hi,

> Primary topics to discuss:
> 
> 1. Memory management (@Anatoly)
> 
>     1.1. MM changed radically since v18.08 and dpdk-next-windows does not
>          implement it properly anyway, it allocates segment lists in a PCI bus
>          driver. My implementation closely follows the Linux one using
>          VirtualAlloc2() with XXX_PLACEHOLDER flags to reserve and commit
>          memory, but does not map hugepages to files. Is there
>          a consensus on MM approach in Windows?
> 
>          Anyway, I think EAL private MM API would have to be changed,
>          because memory reservation, allocation, and mapping are
>          completely different operations. Hiding this with an mmap() shim
>          doesn't look right, because mmap()'s behavior differs even among
>          Unix platforms.
> 
>     1.2. In Windows, there is no /dev/mem to implement rte_virt2iova(),
>          so a simple kernel driver is required for mapping. Moreover,
>          Windows kernel abstracts IOMMU, so those physical addresses may
>          be unsuitable for DMA at all (see below).
> 

I haven't really been following the Windows port much so i have no idea 
of how it works for now.

The main reason DPDK memory management works the way it does is because 
of need to support multiprocess. In order to map memory in all 
processes, we need that space reserved (otherwise there's no guarantee 
that the newly mapped memory segment will be mapped in all processes, 
and it'll cause runtime failure). If it wasn't for that, we could 
allocate memory arbitrarily and as needed. Windows should either follow 
this model, or drop secondary support and go its own way - the internals 
are OS-specific anyway.

If there are changes needed to private memalloc API to support the 
above, that's completely fine - that's why all of this stuff is 
internal-only :) As long as public API stays roughly the same, we should 
be good. Bear in mind that DPDK also supports external memory, you might 
need to make some allowances for that too.

As for IOMMU - we don't support IOVA as VA addressing on FreeBSD, so if 
Windows port can only work with IOVA as PA, that's fine too. The 
question of IOVA mode really boils down to, do we control the DMA 
addresses (IOVA as VA mode), or does the system (IOVA as PA). I'm not 
familiar with how IOMMU works on Windows, but as long as it fits into 
that model and we keep the API, it should also be OK :)

-- 
Thanks,
Anatoly