RE: [PATCH v2] gpudev: pin GPU memory

[John Alexander]

What happens when the Nvidia GPU driver kernel callback occurs to invalidate 
the pinned GPU memory region?  Doesn't the NIC need to cease all DMA transfers 
to/from that region before the kernel callback can complete?

From: Elena Agostini 
Sent: 04 January 2022 13:55
To: NBU-Contact-Thomas Monjalon (EXTERNAL) 
Cc: dev@dpdk.org
Subject: Re: [PATCH v2] gpudev: pin GPU memory

CAUTION: This email originated from outside of the organization. Do not click 
links or open attachments unless you recognize the sender and know the content 
is safe.
> 04/01/2022 03:41, eagost...@nvidia.com:
> > From: Elena Agostini mailto:eagost...@nvidia.com>>
> >
> > Enable the possibility to make a GPU memory area accessible from
> > the CPU.
> >
> > GPU memory has to be allocated via rte_gpu_mem_alloc().
> >
> > This patch allows the gpudev library to pin, through the GPU driver,
> > a chunk of GPU memory and to return a memory pointer usable
> > by the CPU to access the GPU memory area.
> >
> > Signed-off-by: Elena Agostini 
> > mailto:eagost...@nvidia.com>>
> [...]
> > +/**
> > + * @warning
> > + * @b EXPERIMENTAL: this API may change without prior notice.
> > + *
> > + * Pin a chunk of GPU memory to make it accessible from the CPU
>
> You should define what means "pin" exactly.
> Which properties should we expect?
>

Thanks for reviewing, this is the kind of discussion I wanted to have.
Maybe "pin" is too GDRCopy specific oriented.
Here I want to make a GPU memory buffer visible from the CPU. In case
of NVIDIA, this means the GPU memory address has to be pinned (virtual address
doesn't change) and dma-mapped.

Maybe the name should be more like rte_gpu_mem_to_cpu() that's more
explicative and generic.


> > + * using the memory pointer returned by the function.
>
> Which function should return the pointer?
> rte_gpu_mem_pin is returning an int.

Oversight, will fix it.

>
>
> > + * GPU memory has to be allocated via rte_gpu_mem_alloc().
>
> Why pinning is not done by rte_gpu_mem_alloc()?
> Should it be a flag?

rte_gpu_mem_alloc() allocate virtual memory on the GPU that doesn't have
to be necessarily shared (pinned) to make it visible from CPU.

>
> > + *
> > + * @param dev_id
> > + *   Device ID requiring pinned memory.
> > + * @param size
> > + *   Number of bytes to pin.
> > + *   Requesting 0 will do nothing.
> > + * @param ptr
> > + *   Pointer to the GPU memory area to be pinned.
> > + *   NULL is a no-op accepted value.
> > +
> > + * @return
> > + *   A pointer to the pinned GPU memory usable by the CPU, otherwise NULL 
> > and rte_errno is set:
> > + *   - ENODEV if invalid dev_id
> > + *   - EINVAL if reserved flags
>
> Which reserved flags?
>
> > + *   - ENOTSUP if operation not supported by the driver
> > + *   - E2BIG if size is higher than limit
> > + *   - ENOMEM if out of space
>
> Is out of space relevant for pinning?

Yes, let me add it

>
> > + *   - EPERM if driver error
> > + */
> > +__rte_experimental
> > +int rte_gpu_mem_pin(int16_t dev_id, size_t size, void *ptr);

Re: [dpdk-dev] [PATCH v2] doc: announce API changes for Windows compatibility

[John Alexander]

> -Original Message-
> From: dev  On Behalf Of Dmitry Kozlyuk
> Sent: 10 March 2021 23:54
> To: dev@dpdk.org
> Cc: Ferruh Yigit ; Pallavi Kadam
> ; Dmitry Malloy ;
> Narcisa Ana Maria Vasile ; Stephen
> Hemminger ; Tyler Retzlaff
> ; Declan Doherty
> ; Fiona Trahe ; Ashish
> Gupta ; Dmitry Kozlyuk
> ; Ray Kinsella ; Neil Horman
> 
> Subject: [dpdk-dev] [PATCH v2] doc: announce API changes for Windows
> compatibility
> 
> CAUTION: This email originated from outside of the organization. Do not click
> links or open attachments unless you recognize the sender and know the
> content is safe.
> 
> Windows socket headers define `s_addr`, `min`, and `max` macros which
> break structure definitions containing fields with one of these names.
> Undefining those macros would break some consumers as well.
> 
> Example 1:
> 
> #include 
> #include 
> struct in_addr addr;
> /* addr.s_addr = 0; ERROR: s_addr undefined by DPDK */
> 
> Example 2:
> 
> #include 
> #include 
> struct rte_ether_hdr eh;
> /* eh.s_addr.addr_bytes[0] = 0; ERROR: `addr_s` is a macro */
> 
> It is proposed to rename the conflicting fields on DPDK side, because Win32
> API has wider use and is slower and harder to change.
> 
> New names are left unspecified, open suggestions:
> 
> * `struct rte_ether_hdr` (by Stephen Hemminger):
> 
> * `s_addr` -> `ether_shost`
> * `d_addr` -> `ether_dhost` (for consistency)
> 
> * `struct rte_param_log2_range`, `struct rte_crypto_param_range`:
> 
> * `min` -> `minimum`
> * `max` -> `maximum`


The min/max macros in the Windows headers cause issues with C++ projects also 
(breaks std::min/std::max).  The fix there is to "#define NOMINMAX" prior to 
including windows.h, maybe that's appropriate here too?

> 
> For `s_addr`, a workaround is possible to use it until 21.11.
> For `min` and `max`, no workaround seems available. If cryptodev or
> compressdev is going to be enabled on Windows before 21.11, the only
> option seems to use a new name on Windows (using #ifdef).
> 
> Workaround for `s_addr` is to define `struct rte_ether_hdr` in such a away
> that it can be used with or without `s_addr` macro (as defined on Windows):
> 
> #pragma push_macro("s_addr")
> #ifdef s_addr
> #undef s_addr
> #endif
> 
> struct rte_ether_hdr {
> struct rte_ether_addr d_addr; /**< Destination address. */
> RTE_STD_C11
> union {
> struct rte_ether_addr s_addr; /**< Source address. */
> struct {
> struct rte_ether_addr S_un;
> /**< MUST NOT be used directly, only via s_addr */
> } S_addr;
> /**< MUST NOT be used directly, only via s_addr */
> };
> uint16_t ether_type; /**< Frame type. */
> } __rte_aligned(2);
> 
> #pragma pop_macro("s_addr")
> 
> Signed-off-by: Dmitry Kozlyuk 
> ---
> v2: * Propose to rename all problematic fields identified so far.
> * Leave future names unspecified, no need to promise now.
> * Propose better names for MAC addresses (Stephen Hemminger).
> 
> Thread about `s_addr` workaround:
> https://mails.dpdk.org/archives/dev/2021-March/200700.html
> Tyler Retzlaff confirmed offline that Microsoft took similar approach.
> 
>  doc/guides/rel_notes/deprecation.rst | 9 +
>  1 file changed, 9 insertions(+)
> 
> diff --git a/doc/guides/rel_notes/deprecation.rst
> b/doc/guides/rel_notes/deprecation.rst
> index 64629e0641..854618f091 100644
> --- a/doc/guides/rel_notes/deprecation.rst
> +++ b/doc/guides/rel_notes/deprecation.rst
> @@ -130,3 +130,12 @@ Deprecation Notices
>  * cmdline: ``cmdline`` structure will be made opaque to hide platform-
> specific
>content. On Linux and FreeBSD, supported prior to DPDK 20.11,
>original structure will be kept until DPDK 21.11.
> +
> +* net: ``s_addr`` and ``d_addr`` fields of ``rte_ether_hdr`` structure
> +  will be renamed in DPDK 20.11 to avoid conflict with Windows Sockets
> headers.
> +
> +* compressdev: ``min`` and ``max`` fields of ``rte_param_log2_range``
> +structure
> +  will be renamed in DPDK 20.11 to avoid conflict with Windows Sockets
> headers.
> +
> +* cryptodev: ``min`` and ``max`` fields of ``rte_crypto_param_range``
> +structure
> +  will be renamed in DPDK 20.11 to avoid conflict with Windows Sockets
> headers.
> --
> 2.29.2

Re: [dpdk-dev] [PATCH] windows: minor build fixes

[John Alexander]

> -Original Message-
> From: dev  On Behalf Of Nick Connolly
> Sent: 30 October 2020 17:46
> To: Bruce Richardson 
> Cc: dev@dpdk.org; Nick Connolly 
> Subject: [dpdk-dev] [PATCH] windows: minor build fixes
> 
> CAUTION: This email originated from outside of the organization. Do not click
> links or open attachments unless you recognize the sender and know the
> content is safe.
> 
> Don't run symlink-drivers-solibs.sh as part of 'install' because Windows
> doesn't support shell scripts.
> 
> Meson versions >= 0.54.0 include support for handling /implib with msvc
> link. Specifying it explicitly causes failures when linking against the dll. 
> Tested
> using Link 14.27.29112.0 and Clang 11.0.0.
> 
> Signed-off-by: Nick Connolly 
> ---
>  config/meson.build  | 8 +---
>  drivers/meson.build | 6 --
>  lib/meson.build | 6 --
>  3 files changed, 13 insertions(+), 7 deletions(-)
> 
> diff --git a/config/meson.build b/config/meson.build index
> 258b01d06..a29693b88 100644
> --- a/config/meson.build
> +++ b/config/meson.build
> @@ -57,9 +57,11 @@ eal_pmd_path = join_paths(get_option('prefix'),
> driver_install_path)  # driver .so files often depend upon the bus drivers for
> their connect bus,  # e.g. ixgbe depends on librte_bus_pci. This means that
> the bus drivers need  # to be in the library path, so symlink the drivers from
> the main lib directory.
> -meson.add_install_script('../buildtools/symlink-drivers-solibs.sh',
> -   get_option('libdir'),
> -   pmd_subdir_opt)
> +if not is_windows
> +   meson.add_install_script('../buildtools/symlink-drivers-solibs.sh',
> +   get_option('libdir'),
> +   pmd_subdir_opt)
> +endif
> 
>  # set the machine type and cflags for it  if meson.is_cross_build() diff 
> --git
> a/drivers/meson.build b/drivers/meson.build index 4bb7e9218..6b50f7238
> 100644
> --- a/drivers/meson.build
> +++ b/drivers/meson.build
> @@ -186,8 +186,10 @@ foreach subpath:subdirs
> lk_deps = [version_map, def_file, mingw_map]
> if is_windows
> if is_ms_linker
> -   lk_args = ['-Wl,/def:' + 
> def_file.full_path(),
> -   '-Wl,/implib:drivers\\' + 
> implib]
> +   lk_args = ['-Wl,/def:' + 
> def_file.full_path()]
> +   if 
> meson.version().version_compare('<0.54.0')
> +   lk_args += 
> ['-Wl,/implib:drivers\\' + implib]
> +   endif
> else
> lk_args = ['-Wl,--version-script=' +
> mingw_map.full_path()]
> endif
> diff --git a/lib/meson.build b/lib/meson.build index 1bb019720..ed00f8914
> 100644
> --- a/lib/meson.build
> +++ b/lib/meson.build
> @@ -157,8 +157,10 @@ foreach l:libraries
> output: '@0@_mingw.map'.format(libname))
> 
> if is_ms_linker
> -   lk_args = ['-Wl,/def:' + def_file.full_path(),
> -   '-Wl,/implib:lib\\' + implib]
> +   lk_args = ['-Wl,/def:' + def_file.full_path()]
> +   if meson.version().version_compare('<0.54.0')
> +   lk_args += ['-Wl,/implib:lib\\' + 
> implib]
> +   endif
> else
> if is_windows
> lk_args = ['-Wl,--version-script=' +
> mingw_map.full_path()]
> --
> 2.25.1

Hi,

Do we know what the motivation to rename the import library for the Windows 
build was in the first place?  I've tried removing the renaming of the import 
library completely in the Windows build and the build produces valid output (a 
valid DLL and paired import library is generated for each RTE lib using clang 
build); The meson version test addition may be unnecessary here?

Kind Regards,
John Alexander.

Re: [dpdk-dev] Windows DPDK real-time priority threads causing thread starvation

[John Alexander]

Hi,

I tend to run with a winbdg kernel debugger (KDNET) connected to my debug 
target machines.  It quite often reports deadlock detection when we have such 
"real-time" threads never yielding on a core.  If we hog core-0 in particular 
dwm.exe never gets a look in so the desktop stops being drawn too.

John.

> -Original Message-
> From: dev  On Behalf Of Tal Shnaiderman
> Sent: 09 December 2020 14:16
> To: Dmitry Kozlyuk ; Dmitry Malloy
> (MESHCHANINOV) ; Narcisa Ana Maria Vasile
> 
> Cc: Eilon Greenstein ; Omar Cardona
> ; Rani Sharoni ; Odi Assli
> ; Harini Ramakrishnan
> ; NBU-Contact-Thomas Monjalon
> ; dev@dpdk.org
> Subject: [dpdk-dev] Windows DPDK real-time priority threads causing thread
> starvation
> 
> CAUTION: This email originated from outside of the organization. Do not click
> links or open attachments unless you recognize the sender and know the
> content is safe.
> 
> Hi,
> 
> During our verification tests on Windows DPDK we've noticed that DPDK
> polling threads, which run in REALTIME_PRIORITY_CLASS are causing
> starvation to other threads from the OS which need to change affinity and
> run in lower priority.
> 
> While running an application for a while we see the OS thread waits for 2:30
> minutes and raises a bugcheck, see below example of such flow:
> 
> 1) DPDK thread running on core-0 in real-time high priority(24) polling mode.
> 2) The thread is blocking the system function NtSetSystemInformation
> (ExpUpdateTimerConfiguration) in another thread from
>switching to core-0 via KeSetSystemGroupAffinityThread since the calling
> thread is priority 15.
> 3) NtSetSystemInformation exclusively acquired system-wide lock
> (ExpTimeRefreshLock) hence
> it blocks other threads (e.g. calling NtQuerySystemInformation).
> 
> We've seen this behavior only while running on Windows 2019 VMs, maybe
> on native machines OS scheduling of such flow is done differently?
> 
> Below is usage explanation from the documentation of SetPriorityClass [1]:
> 
> - REALTIME_PRIORITY_CLASS
> Process that has the highest possible priority. The threads of the process
> preempt the threads of all other processes, including operating system
> processes performing important tasks. For example, a real-time process that
> executes for more than a very brief interval can cause disk caches not to
> flush or cause the mouse to be unresponsive.
> 
> So I assume using this kind of thread for a long period as we do can cause
> unstable behavior.
> 
> How do you think we can resolve this? Are there such cases in Linux?
> 
> [1] - https://docs.microsoft.com/en-
> us/windows/win32/api/processthreadsapi/nf-processthreadsapi-
> setpriorityclass
> 
> Thanks,
> 
> Tal.

[dpdk-dev] [PATCH] eal/windows: Switched to an external pthreads library, pulled in as a meson subproject

[John Alexander]

The Windows EAL build now pulls in the pthreads4w project as an external 
subproject.  The pthreads4w subproject does not currently provide a meson build 
so the project has been patched with one.

Removed the placeholder librte_eal\windows\include\pthread.h and sched.h header 
files as these are superseded by the pthreads4w implementation.

rte_eal_init() in the Windows EAL has been modified to use pthread_create() and 
pthread_setaffinity_np() to setup the secondary lcores.  eal_thread_create() 
has been removed as it is no longer required.

rte_eal_init() in the Windows EAL now calls SetPriorityClass() to set the 
process class to real-time in a singular location.

eal_thread_loop() in the Windows EAL now calls SetThreadPriority() to set the 
thread priority to real-time when the thread commences execution.  This 
function now uses pthreads functions to test and compare pthread_t handles.

Added the source file librte_eal\windows\windows_eal_impl.c.  This source file 
serves as a location for the implementation of auxillary functionality provided 
by the Windows EAL that would otherwise be provided by the UNIX runtime.

Added the pthreads4w shared library as a dependency to EAL library builds for 
Windows builds only.  The meson install step will install the pthreads4w.dll 
that is built by the meson external subproject build step.  The shared library 
has been selected for both static and shared library builds to avoid 
constructior initialisation issues observed when using pthreads4w and static 
linkage within the DPDK project.

Added the subprojects folder to the .gitignore file such that authoered content 
is not ignored and downloaded content is ignored (as that's where meson stores 
the subprojects when they are cloned).

Incremented the minimum meson version number to 0.55.0.  This is required to 
use the subproject folder patch feature.

Updated MAINTAINERS to reflect new additions.
---
 .gitignore|   6 +
 MAINTAINERS   |   3 +
 lib/librte_eal/windows/eal.c  |  21 ++-
 lib/librte_eal/windows/eal_thread.c   |  27 +---
 lib/librte_eal/windows/eal_windows.h  |  10 --
 lib/librte_eal/windows/include/pthread.h  | 146 --
 lib/librte_eal/windows/include/rte_os.h   |  15 +-
 lib/librte_eal/windows/include/sched.h|  92 ---
 lib/librte_eal/windows/meson.build|   1 +
 lib/librte_eal/windows/windows_eal_impl.c |  56 +++
 lib/meson.build   |  14 +-
 meson.build   |   7 +-
 .../packagefiles/pthreads4w-meson/VERSION |   1 +
 .../packagefiles/pthreads4w-meson/meson.build |  49 ++
 subprojects/pthreads4w-code.wrap  |   8 +
 15 files changed, 181 insertions(+), 275 deletions(-)
 delete mode 100644 lib/librte_eal/windows/include/pthread.h
 delete mode 100644 lib/librte_eal/windows/include/sched.h
 create mode 100644 lib/librte_eal/windows/windows_eal_impl.c
 create mode 100644 subprojects/packagefiles/pthreads4w-meson/VERSION
 create mode 100644 subprojects/packagefiles/pthreads4w-meson/meson.build
 create mode 100644 subprojects/pthreads4w-code.wrap

diff --git a/.gitignore b/.gitignore
index f73d93ca5..3792a843b 100644
--- a/.gitignore
+++ b/.gitignore
@@ -33,3 +33,9 @@ build-*
 # ignore other build directory patterns
 *-gcc*
 *-clang*
+
+# ignore sub-directories of the subprojects directory excluding wrap files and 
the packagefiles directory
+subprojects/**/*
+!subprojects/*.wrap
+!subprojects/packagefiles/
+!subprojects/packagefiles/**
diff --git a/MAINTAINERS b/MAINTAINERS
index c0abbe0fc..c33c1bc72 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -318,10 +318,13 @@ M: Dmitry Kozlyuk 
 M: Narcisa Ana Maria Vasile 
 M: Dmitry Malloy 
 M: Pallavi Kadam 
+M: John Alexander 
 F: lib/librte_eal/windows/
+F: lib/librte_eal/windows/windows_eal_impl.c
 F: lib/librte_eal/rte_eal_exports.def
 F: buildtools/map_to_win.py
 F: doc/guides/windows_gsg/
+F: subprojects/
 
 Windows memory allocation
 M: Dmitry Kozlyuk 
diff --git a/lib/librte_eal/windows/eal.c b/lib/librte_eal/windows/eal.c
index bc48f27ab..86121dc6a 100644
--- a/lib/librte_eal/windows/eal.c
+++ b/lib/librte_eal/windows/eal.c
@@ -260,7 +260,7 @@ rte_eal_cleanup(void)
 int
 rte_eal_init(int argc, char **argv)
 {
-   int i, fctret, bscan;
+   int i, fctret, bscan, ret;
const struct rte_config *config = rte_eal_get_configuration();
struct internal_config *internal_conf =
eal_get_internal_configuration();
@@ -360,6 +360,15 @@ rte_eal_init(int argc, char **argv)
return -1;
}
 
+   /*
+* We require real-time priority threads.  To achieve this on Windows 
we must
+* set the current process class to real-time.  Setting the process 
class to
+* real-time requires elevated privileges (admin user) otherwise the 
maximum
+* achie

[dpdk-dev] [PATCH v2] eal/windows: Switched to an external pthreads library

[John Alexander]

The Windows EAL build now pulls in the pthreads4w project as an external
subproject.  The pthreads4w subproject does not currently provide a
meson build so the project has been patched with one.

Removed the placeholder librte_eal\windows\include\pthread.h and sched.h
header files as these are superseded by the pthreads4w implementation.

rte_eal_init() in the Windows EAL has been modified to use
pthread_create() and pthread_setaffinity_np() to setup the secondary
lcores.  eal_thread_create() has been removed as it is no longer
required.

rte_eal_init() in the Windows EAL now calls SetPriorityClass() to set
the process class to real-time in a singular location.

eal_thread_loop() in the Windows EAL now calls SetThreadPriority() to
set the thread priority to real-time when the thread commences execution.
This function now uses pthreads functions to test and compare pthread_t
handles.

Added the source file librte_eal\windows\windows_eal_impl.c.  This source
file serves as a location for the implementation of auxiliary
functionality provided by the Windows EAL that would otherwise be provided
by the UNIX runtime.

Added the pthreads4w shared library as a dependency to EAL library builds
for Windows builds only.  The meson install step will install the
pthreads4w.dll that is built by the meson external subproject build step.
The shared library has been selected for both static and shared library
builds to avoid constructior initialisation issues observed when using
pthreads4w and static linkage within the DPDK project.

Added the subprojects folder to the .gitignore file such that authored
content is not ignored and downloaded content is ignored (as that's where
meson stores the subprojects when they are cloned).

Incremented the minimum meson version number to 0.55.0.  This is required
to use the subproject folder patch feature.

Updated MAINTAINERS to reflect new additions.

Signed-off-by: John Alexander 
---
 .gitignore|   6 +
 MAINTAINERS   |   3 +
 lib/librte_eal/windows/eal.c  |  21 ++-
 lib/librte_eal/windows/eal_thread.c   |  27 +---
 lib/librte_eal/windows/eal_windows.h  |  10 --
 lib/librte_eal/windows/include/pthread.h  | 146 --
 lib/librte_eal/windows/include/rte_os.h   |  15 +-
 lib/librte_eal/windows/include/sched.h|  92 ---
 lib/librte_eal/windows/meson.build|   1 +
 lib/librte_eal/windows/windows_eal_impl.c |  53 +++
 lib/meson.build   |  14 +-
 meson.build   |   7 +-
 .../packagefiles/pthreads4w-meson/VERSION |   1 +
 .../packagefiles/pthreads4w-meson/meson.build |  49 ++
 subprojects/pthreads4w-code.wrap  |   8 +
 15 files changed, 178 insertions(+), 275 deletions(-)
 delete mode 100644 lib/librte_eal/windows/include/pthread.h
 delete mode 100644 lib/librte_eal/windows/include/sched.h
 create mode 100644 lib/librte_eal/windows/windows_eal_impl.c
 create mode 100644 subprojects/packagefiles/pthreads4w-meson/VERSION
 create mode 100644 subprojects/packagefiles/pthreads4w-meson/meson.build
 create mode 100644 subprojects/pthreads4w-code.wrap

diff --git a/.gitignore b/.gitignore
index f73d93ca5..3792a843b 100644
--- a/.gitignore
+++ b/.gitignore
@@ -33,3 +33,9 @@ build-*
 # ignore other build directory patterns
 *-gcc*
 *-clang*
+
+# ignore sub-directories of the subprojects directory excluding wrap files and 
the packagefiles directory
+subprojects/**/*
+!subprojects/*.wrap
+!subprojects/packagefiles/
+!subprojects/packagefiles/**
diff --git a/MAINTAINERS b/MAINTAINERS
index c0abbe0fc..c33c1bc72 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -318,10 +318,13 @@ M: Dmitry Kozlyuk 
 M: Narcisa Ana Maria Vasile 
 M: Dmitry Malloy 
 M: Pallavi Kadam 
+M: John Alexander 
 F: lib/librte_eal/windows/
+F: lib/librte_eal/windows/windows_eal_impl.c
 F: lib/librte_eal/rte_eal_exports.def
 F: buildtools/map_to_win.py
 F: doc/guides/windows_gsg/
+F: subprojects/
 
 Windows memory allocation
 M: Dmitry Kozlyuk 
diff --git a/lib/librte_eal/windows/eal.c b/lib/librte_eal/windows/eal.c
index bc48f27ab..28320a769 100644
--- a/lib/librte_eal/windows/eal.c
+++ b/lib/librte_eal/windows/eal.c
@@ -260,7 +260,7 @@ rte_eal_cleanup(void)
 int
 rte_eal_init(int argc, char **argv)
 {
-   int i, fctret, bscan;
+   int i, fctret, bscan, ret;
const struct rte_config *config = rte_eal_get_configuration();
struct internal_config *internal_conf =
eal_get_internal_configuration();
@@ -360,6 +360,15 @@ rte_eal_init(int argc, char **argv)
return -1;
}
 
+   /*
+* We require real-time priority threads.  To achieve this on Windows 
we must
+* set the current process class to real-time.  Setting the process 
class to
+* real-time requires elevated privileges (admin user) otherwise the 
ma

[dpdk-dev] Meson Minimum Version

[John Alexander]

Hi,

I've submitted a patch that uses new features of Meson, specifically the 
directory patch aspect of the subproject feature.  This requires a minimum 
Meson version of 0.55.0.  How do we go about getting the community to accept a 
more recent version of Meson and getting the Travis server upgraded too so the 
CI builds succeed?

Patch link for reference: http://patches.dpdk.org/patch/78675/

Kind Regards,
John Alexander.

Re: [dpdk-dev] Meson Minimum Version

[John Alexander]

Hi,

Regarding the subproject local patch support, yes, it's only supported since 
Meson 0.55: https://mesonbuild.com/Wrap-dependency-system-manual.html  We pip 
installed 0.55 Meson.

I have a number of subsequent patches that depend on this particular pthreads 
library to advance the Windows DPDK support.  Locally, we have testpmd (minus 
mmap'd external memory currently) running against the Intel i40e PMD (XL710 
4x10Gbps SPF+ NIC) on Windows on our local DPDK fork (based off 20.08-rc2 using 
Microsoft's latest NetUIO driver).  We have 47 of the 51 RTE libraries building 
and have had l2fwd, l3fwd, ipv4_multicast and almost all of the regression 
tests compiling+linking too.I'd like to push as much of the Windows EAL 
work we've done upstream if I can (after a bit of tidying up :).
 
I've also coded up a meson build patch for the Jansson JSON parser used by the 
RTE metrics library (the config.h generation was quite fiddly!)  That's ready 
to go.  We get nice meson syntax as follows to specify a fallback if the 
library isn't installed locally:
jansson = dependency('jansson', required: false, fallback : ['jansson', 
'jansson_static_dep'])
I believe the meson command line enables disabling fallbacks if people would 
prefer not to use them (--wrap-mode=nofallback).

Kind regards,
John.

--


Date: Thu, 24 Sep 2020 15:38:30 +0100
From: Bruce Richardson 
To: John Alexander 
Cc: "dev@dpdk.org" , techbo...@dpdk.org
Subject: Re: [dpdk-dev] Meson Minimum Version
Message-ID: <20200924143830.gd...@bricha3-mobl.ger.corp.intel.com>
Content-Type: text/plain; charset=us-ascii

On Thu, Sep 24, 2020 at 02:22:03PM +, John Alexander wrote:
> Hi,
>
> I've submitted a patch that uses new features of Meson, specifically the 
> directory patch aspect of the subproject feature.  This requires a minimum 
> Meson version of 0.55.0.  How do we go about getting the community to accept 
> a more recent version of Meson and getting the Travis server upgraded too so 
> the CI builds succeed?
>
> Patch link for reference: http://patches.dpdk.org/patch/78675/
>
Hi John,

from what I understand the specific dependency on 0.55 is the support for local 
patchfiles for the wrapped software, and that previous versions only supported 
using patches pulled remotely - is that correct?

While I'm in favour of incrementing the minimum meson version in general, since 
0.55 is the very latest version I am worried about any impacts that might have, 
since it will basically mean that everyone building DPDK has to pull meson from 
pip rather than being able to use a distro-supplied version. Updating to 
something a little less recent would be more my preference.

Then again, using the wrap system to pull in dependencies seems something 
really good to have, so maybe the initial pain of requiring a recent meson is 
worth it!

Thoughts from others?

Regards,
/Bruce

Re: [dpdk-dev] [PATCH v2] eal/windows: export all built functions for clang

[John Alexander]

> -Original Message-
> From: dev  On Behalf Of Tal Shnaiderman
> Sent: 07 October 2020 08:20
> To: dev@dpdk.org
> Cc: tho...@monjalon.net; pallavi.ka...@intel.com;
> dmitry.kozl...@gmail.com; ranjit.me...@intel.com;
> navas...@linux.microsoft.com; dmit...@microsoft.com;
> ophi...@nvidia.com
> Subject: [dpdk-dev] [PATCH v2] eal/windows: export all built functions for
> clang
> 
> CAUTION: This email originated from outside of the organization. Do not click
> links or open attachments unless you recognize the sender and know the
> content is safe.
> 
> export for clang build all the functions currently built on Windows and listed
> in rte_eal_version.map by adding them to rte_eal_exports.def.
> 
> Signed-off-by: Tal Shnaiderman 
> Acked-by: Ranjit Menon 
> ---
> v2: rebase to master
> ---
> ---
>  lib/librte_eal/rte_eal_exports.def | 156
> +++--
>  1 file changed, 151 insertions(+), 5 deletions(-)
> 
> diff --git a/lib/librte_eal/rte_eal_exports.def
> b/lib/librte_eal/rte_eal_exports.def
> index 7b35beb702..d7a47d0929 100644
> --- a/lib/librte_eal/rte_eal_exports.def
> +++ b/lib/librte_eal/rte_eal_exports.def
> @@ -3,34 +3,83 @@ EXPORTS
> per_lcore__lcore_id
> per_lcore__rte_errno
> per_lcore__thread_id
> +   rte_bus_dump
> +   rte_bus_find
> +   rte_bus_find_by_device
> +   rte_bus_find_by_name
> +   rte_bus_get_iommu_class
> +   rte_bus_probe
> rte_bus_register
> +   rte_bus_scan
> +   rte_bus_unregister
> rte_calloc
> rte_calloc_socket
> rte_cpu_get_flag_enabled
> +   rte_cpu_get_flag_name
> +   rte_ctrl_thread_create
> +   rte_delay_us
> +   rte_delay_us_block
> +   rte_delay_us_callback_register
> rte_dev_is_probed
> +   rte_dev_probe
> +   rte_dev_remove
> +   rte_devargs_add
> +   rte_devargs_dump
> rte_devargs_insert
> rte_devargs_next
> rte_devargs_parse
> +   rte_devargs_parsef
> rte_devargs_remove
> +   rte_devargs_type_count
> +   rte_dump_physmem_layout
> +   rte_dump_registers
> +   rte_dump_stack
> +   rte_dump_tailq
> +   rte_eal_cleanup
> +   rte_eal_get_lcore_state
> +   rte_eal_get_physmem_size
> +   rte_eal_get_runtime_dir
> rte_eal_has_hugepages
> rte_eal_has_pci
> +   rte_eal_hotplug_add
> +   rte_eal_hotplug_remove
> rte_eal_init
> rte_eal_iova_mode
> +   rte_eal_lcore_role
> rte_eal_mbuf_user_pool_ops
> rte_eal_mp_remote_launch
> rte_eal_mp_wait_lcore
> rte_eal_process_type
> rte_eal_remote_launch
> -   rte_log
> rte_eal_tailq_lookup
> rte_eal_tailq_register
> rte_eal_using_phys_addrs
> +   rte_eal_wait_lcore
> +   rte_exit
> rte_free
> +   rte_get_master_lcore
> +   rte_get_next_lcore
> rte_get_tsc_hz
> rte_hexdump
> +   rte_hypervisor_get
> rte_intr_rx_ctl
> +   rte_lcore_count
> +   rte_lcore_has_role
> +   rte_lcore_index
> +   rte_lcore_is_enabled
> +   rte_lcore_to_socket_id
> +   rte_log
> +   rte_log_cur_msg_loglevel
> +   rte_log_cur_msg_logtype
> +   rte_log_dump
> +   rte_log_get_global_level
> +   rte_log_get_level
> +   rte_log_get_stream
> rte_log_register
> +   rte_log_set_global_level
> rte_log_set_level
> +   rte_log_set_level_pattern
> +   rte_log_set_level_regexp
> rte_malloc
> rte_malloc_dump_stats
> rte_malloc_get_socket_stats
> @@ -53,6 +102,7 @@ EXPORTS
> rte_mem_lock_page
> rte_mem_virt2iova
> rte_mem_virt2phy
> +   rte_memdump
> rte_memory_get_nchannel
> rte_memory_get_nrank
> rte_memzone_dump
> @@ -62,16 +112,53 @@ EXPORTS
> rte_memzone_reserve_aligned
> rte_memzone_reserve_bounded
> rte_memzone_walk
> +   rte_openlog_stream
> +   rte_realloc
> +   rte_rtm_supported
> +   rte_service_attr_get
> +   rte_service_attr_reset_all
> +   rte_service_component_register
> +   rte_service_component_runstate_set
> +   rte_service_component_unregister
> +   rte_service_dump
> +   rte_service_finalize
> +   rte_service_get_by_name
> +   rte_service_get_count
> +   rte_service_get_name
> +   rte_service_lcore_add
> +   rte_service_lcore_attr_get
> +   rte_service_lcore_attr_reset_all
> +   rte_service_lcore_count
> +   rte_service_lcore_count_services
> +   rte_service_lcore_del
> +   rte_service_lcore_list
> +   rte_service_lcore_reset_all
> +   rte_service_lcore_start
> +   rte_service_lcore_stop
> +   rte_service_map_lcore_get
> +   rte_service_map_lcore_set
> +   rte_service_may_be_active
> +   rte_service_probe_capability
> +   rte_service_run_iter_on_app_lcore
> +   rte_service_ru

Re: [dpdk-dev] Meson Minimum Version

[John Alexander]

> On Thu, Sep 24, 2020 at 02:22:03PM +0000, John Alexander wrote:
> > Hi,
> >
> > I've submitted a patch that uses new features of Meson, specifically the
> directory patch aspect of the subproject feature.  This requires a minimum
> Meson version of 0.55.0.  How do we go about getting the community to
> accept a more recent version of Meson and getting the Travis server
> upgraded too so the CI builds succeed?
> >
> > Patch link for reference: http://patches.dpdk.org/patch/78675/
> >
> > Kind Regards,
> > John Alexander.
> 
> Hi John,
> 
> this meson version change came up for discussion at the last DPDK technical
> board meeting, and some concerns were expressed about the jump in
> version and how it might impact those trying to package DPDK.
> 
> However, looking at your proposed patch, I wonder though if we really need
> to globally bump the meson version, and whether we can limit the
> requirements to just windows builds - which is what your patch targets.
> Would the following change to your patch work for you? It keeps the
> minimum meson version at 0.47.1 but then later does a windows-specific
> version check, printing out an error message if requirements not met?
> 
> /Bruce
> 
> $ git diff
> diff --git a/config/meson.build b/config/meson.build index
> 69f2aeb60..fd48c9828 100644
> --- a/config/meson.build
> +++ b/config/meson.build
> @@ -14,6 +14,11 @@ foreach env:supported_exec_envs
> set_variable('is_' + env, exec_env == env)  endforeach
> 
> +# for windows, we need meson 0.55
> +if is_windows and meson.version().version_compare('< 0.55')
> +   error('Require meson 0.55 to build on windows') endif
> +
>  # MS linker requires special treatment.
>  # TODO: use cc.get_linker_id() with Meson >= 0.54  is_ms_linker =
> is_windows and (cc.get_id() == 'clang') diff --git a/meson.build b/meson.build
> index 9e061c73b..7dba3264e 100644
> --- a/meson.build
> +++ b/meson.build
> @@ -8,7 +8,7 @@ project('DPDK', 'C',
> files('VERSION')).stdout().strip(),
> license: 'BSD',
> default_options: ['buildtype=release', 'default_library=static'],
> -   meson_version: '>= 0.55.0'
> +   meson_version: '>= 0.47.1'
>  )
> 
>  # set up some global vars for compiler, platform, configuration, etc.
> 

Hi Bruce,

Thanks for the workaround suggestion.  That certainly works for me.

Kind Regards,
John Alexander.