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
