[dpdk-dev] Windows Support Plan
Thomas Monjalon
thomas at monjalon.net
Wed Feb 5 02:03:22 CET 2020
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
More information about the dev
mailing list