Re: [dpdk-dev] DPDK Windows Build
Hello Jeremy, > clang: error: no such file or directory: '/OPT:REF' There is a bug in Meson: '/OPT:REF' must be prefixed with '-Wl,' when using Clang with link.exe, because Clang does not recognize '/OPT:REF' as an argument to pass to linker, but treats it as a filename instead. A patch is not under review: https://github.com/mesonbuild/meson/pull/6483 I was able to successfully build DPDK after applying this patch to Meson.
Re: [dpdk-dev] [PATCH v6 03/10] eal: include filesystem implementation for windows
Hello Pallavi,
> +#include "eal_internal_cfg.h"
> +
> +/* sets up platform-specific runtime data dir */
> +int
> +eal_create_runtime_dir(void);
> +
> +/* returns runtime dir */
> +const char *
> +eal_get_runtime_dir(void);
Any reason not to #include "eal_filesystem.h"?
> +
> +static inline const char *
> +eal_runtime_config_path(void)
> +{
> + static char buffer[PATH_MAX]; /* static so auto-zeroed */
> + char Directory[PATH_MAX];
Should be "directory" according to the style guide.
> +
> + GetTempPathA(sizeof(Directory), Directory);
> + snprintf(buffer, sizeof(buffer)-1, RUNTIME_CONFIG_FMT, Directory,
Style guide requires spaces around binary "-".
> +static inline const char *
> +eal_hugepage_info_path(void)
> +{
> + static char buffer[PATH_MAX]; /* static so auto-zeroed */
> + TCHAR Directory[PATH_MAX];
Should be "directory", see above.
Re: [dpdk-dev] DPDK Windows Build
Hi William, > Sanity check compile stderr: > clang.exe: error: linker command failed with exit code 1104 (use -v to > see invocation) Please add '-v' flag to Meson invocation and post the output as plain text. The exact commands you're using will also help. > Program cat found: YES (C:\MinGW\msys\1.0\bin\cat.EXE) I suspect MSYS confuses Meson and it may call 'clang.exe' instead of 'clang-cl.exe'. Try excluding MSYS from your PATH. -- Dmitry Kozlyuk
[dpdk-dev] Windows Support Plan
Hi everyone! Where do I find a high-level plan of comprehensive Windows support: design decisions, implementation order, etc? 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. 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. 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). 2. Kernel drivers (@Harini, @Stephen) 2.1. The most serious issue is that Windows formally prohibits using arbitrary physical addresses with DMA in favor of allocating special buffers (presumably because IOMMU may be engaged, and there is no way to check). We can either live with it (technically, everything works with PA mode), or we could revive DMA allocation API from ethdev to ask the driver for a proper DMA buffer. 2.2. Neither netuio, nor my driver (userpci) support interrupts. I see not inherent difficulty here, but interface should be designed carefully. 2.3. Windows allows mapping I/O ports into user-space, but there is no API to change IOPL, which makes mapping useless and requires a syscall for every I/O port access. This demolishes virtio-legacy performance. Perhaps Microsoft could give some advice here. OTOH, PIO is all legacy, so might be much effort is not justified. 2.4. I believe GUIDs approach for identifying compatible devices should be strictly preferred, and not DosDevices symlinks. Think of Mellanox OFED on Linux, which uses a different driver, but could provide a compatible interface. Another reason is that a single driver can implement multiple kernel interfaces with appropriate GUIDs. 2.5. DPDK Windows driver guidelines, driver review, and certification. The quality of both netuio and userpci is below standards now (e. g. netuio does not mind its context when mapping memory, and userpci lacks synchronization), code style is a mix of Windows and DPDK, logging may be insufficient. 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)? IMO creating a shim is wrong. 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: * , which is header-only. * Berkeley sockets. Adding to public headers creates more trouble that its worth: definitions for a few structures and constants. May be there should be some to abstract platform differences. Some highlights on my implementation: * Major features NOT supported: * multi-process (due to limited time) * interrupts (limited time + explained above) * eventdev (requires access to physical memory) * hot-plug (due to limited time and Windows knowledge) * bbdev (see comments in config/common_windows) * FreeBSD (trivial, I just don't use
Re: [dpdk-dev] DPDK Windows Build
> > Do I mess up some linker's configurations? > I attached the meson log, thanks for your help! Those are not errors, just harmless warnings. You can now build and run an example program (rerun meson with -Dexamples=helloworld per Windows Getting Started Guide).
Re: [dpdk-dev] [PATCH v2 0/7] MinGW-w64 support
Hi William, I applied your v2 patch and I did a native build on windows 10. > Hit an error showing > ../lib/librte_eal/windows/eal/eal_lcore.c:54:2: error: 'for' loop > initial declarations are only allowed in C99 mode > Thanks, will fix in v3. However the output looks weird: > C:\dpdk\build\examples>dpdk-helloworld.exe > EAL: Detected 2 lcore(s) > EAL: Detected 1 NUMA nodes > hehello fllo frorom cm core 1 > ore 0 > It looks like your stdout is unbuffered (default is line-buffered). What terminal are you using (cmd, Power Shell, Terminal App, conemu, etc)? C compiler for the host machine: cc (gcc 4.8.3 "cc (GCC) 4.8.3") > GCC 4.8.3 is quite outdated, MinGW-w64 ships GCC 8 nowadays. Do we need to support it for Windows (I doubt MinGW-w64 does)? -- Dmitry Kozlyuk >
Re: [dpdk-dev] [PATCH v8 03/11] eal: introduce memory management wrappers
> [...]
> > +INTERNAL {
> > + global:
> > +
> > + rte_mem_lock;
> > + rte_mem_map;
> > + rte_mem_page_size;
> > + rte_mem_unmap;
> > +};
>
> Not sure why these functions are internal.
> They may be useful for DPDK applications.
> We would need to add the file in doxygen index.
>
Not sure if they are in DPDK scope, apart from rte_mem_lock, which
generalizes rte_mem_lock_page already in rte_memory.h. What may be typical
use cases for data-plane apps? I can see testpmd using mmap for allocating
external memory (because of possible use of hugepages), does it need these
functions exposed?
> If we want to keep them internal, we should add a doxygen marker
> @internal.
>
IIRC, it were you who proposed making them internal instead of
experimental. And internal symbols can always be exposed later.
> > +#include
>
> I think we should find a better file name for these wrappers.
> "EAL memory" means DPDK memory allocator in my mind.
> We need a file name which is about OS-independent wrappers,
> or libc wrappers.
> What about rte_libc_mem.h? rte_mem_os.h? something else?
See above, but anyway, "libc" is non-generic.
Re: [dpdk-dev] [PATCH v8 03/11] eal: introduce memory management wrappers
> > > Not sure if they are in DPDK scope, apart from rte_mem_lock, which > > generalizes rte_mem_lock_page already in rte_memory.h. What may be > typical > > use cases for data-plane apps? I can see testpmd using mmap for > allocating > > external memory (because of possible use of hugepages), does it need > these > > functions exposed? > > There is a chance the application needs such functions > for another part of its dataplane. Such reasoning can justify any API. DPDK needs compatibility layers, but collecting and providing them is not the goal of the kit. I can only think of using mmap in data plane as a high-performance IPC with non-DPDK management app. Please add the @internal tag in doxygen to make the status clear. > OK. > > > > +#include > > > > > > I think we should find a better file name for these wrappers. > > > "EAL memory" means DPDK memory allocator in my mind. > > > We need a file name which is about OS-independent wrappers, > > > or libc wrappers. > > > What about rte_libc_mem.h? rte_mem_os.h? something else? > > > > See above, but anyway, "libc" is non-generic. > > Why libc is not generic? > It means nothing on Windows. Also, mmap has little to do with libc. Which file name can it be? > Your rte_mem_os.h sounds good, except internal header better be rte_eal_mem_os.h. Alternative: rte_eal_paging.h. >
Re: [dpdk-dev] [PATCH v4 25/27] eal: mark old naming as deprecated
On Fri, Jul 17, 2020, 18:21 Burakov, Anatoly
wrote:
> On 16-Jul-20 11:04 PM, Stephen Hemminger wrote:
> > On Thu, 16 Jul 2020 14:41:41 +0100
> > "Burakov, Anatoly" wrote:
> >
> >> On 15-Jul-20 9:29 PM, Stephen Hemminger wrote:
> >>> On Wed, 15 Jul 2020 14:28:17 +0100
> >>> "Burakov, Anatoly" wrote:
> >>>
> > -#define SKIP_MASTER SKIP_INITIAL
> > -#define CALL_MASTER CALL_INITIAL
> > +#define SKIP_MASTER _Pragma("GCC warning \"'SKIP_MASTER' is
> deprecated\"") SKIP_INITIAL
> > +#define CALL_MASTER _Pragma("GCC warning \"'CALL_MASTER' is
> deprecated\"") CALL_INITIAL
>
> Presumably this is a generic header, should we introduce GCC-specific
> things there?
> >>>
> >>> It works with Clang as well. Likely ICC but don't have that.
> >>>
> >>
> >> What about MSVC?
>
FYI, DPDK on Windows is compiled with Clang, only linker is from MSVC. And
MinGW uses GCC toolchain. Why care about MSVC here?
