Re: [dpdk-dev] Windows Support Plan

[Thomas Monjalon <thomas@monjalon.net>]

02/02/2020 21:37, Dmitry Kozliuk:
> Where do I find a high-level plan of comprehensive Windows support: design
> decisions, implementation order, etc?

Please help documenting design decisions in the DPDK doc.
For implementation order, we'll discuss it soon together.

> Information on the subject is very scarce, one may think it is abandoned.
> Googling for "site:dpdk.org/ml/archives/dev/ windows" yields only two pages
> of disjoint messages. I learned about "netuio" days ago from a tiny remark in
> a "Minutes of Technical Board Meetings" email, and even then it took
> enumerating "dpdk-next-windows" branches to find the source.

I agree.
I think Harini will address this lack of information.

> The matter is, as a New Year's holiday project of mine I implemented Windows
> support from scratch to the point it runs in QEMU with virtio-pci [0]. It is
> not of production quality, cuts some corners and lacks major features (see
> bottom). My primary goal was fun^W making it work. Comparing it to
> "windpdk-v18.08" branch of "dpdk-next-windows", I can see that 1) our
> implementations take rather different approaches in some cases, and 2) both
> have severe issues and would benefit from amalgamation. I'd like to
> contribute to Windows support with this code, but to do so, coordination is
> required, because changes are significant.

You are very welcome.
The work you already did looks amazing and it is very well presented.

[...]
> 3. POSIX shim vs EAL wrappers (@Thomas, @Pallavi, @Ranjit)
> 
>    What is the policy: to implement a POSIX shim in EAL (as the latest
>    patches from Pallavi Kadam do), or to add dependencies (as [1] suggests)?

You are right, we should think about adding new dependencies which are
easily and generally available.

>    IMO creating a shim is wrong.

I do not like the shim layer either.

>    First, some POSIX concepts do not
>    easily map to Windows, like poll() interface and I/O model in
>    general. Second, there are numerous getopt, pthread, etc.
>    implementations for Windows, no point wasting resources and repeat
>    them, adding bugs. I can think of two exceptions:
> 
>    * <sys/queue.h>, which is header-only.
> 
>    * Berkeley sockets. Adding <winsock2.h> to public headers creates
>      more trouble that its worth: definitions for a few structures and
>      constants. May be there should be some <rte_socket.h> to abstract
>      platform differences.
[...]
>   * multi-process (due to limited time)

As Anatoly said, multi-process is not a priority.
This feature has a high cost, so we should think twice before deciding
to support it on Windows.

[...]
> [0]: https://github.com/PlushBeaver/dpdk/commits/windows
> [1]: http://mails.dpdk.org/archives/dev/2015-February/014245.html

Thanks a lot