build them. The script currently
handles Clang and GCC.
On Linux the functionality is unchanged, but could be replaced with the
python script once the required minimum version of meson is >= 0.55.0.
Fixes: 5c7d86948764 ("build: fix install on Windows")
Cc: sta...@dpdk.org
Signed-off-b
This shim could have been convenient for applications.
If not named "internal", we could export the header file
and allow apps including it.
Otherwise the app can recreate this file on its side,
it is not a big deal.
Opinions?
Based on my experience with SPDK, I believe this would get messy
v
Also, I don't think this is a thread specific function, other implementations
can use it in the future, maybe move it to rte_windows.h?
I'd suggest that it's probably better suited to a .c file rather
than a header. As an example of what it might end up like
see https://github.com/wpdk/wpdk
>
> I don't understand your point.
> I am just proposing to allow some apps to explicitly include the shim
> for their convenience in case they are fully based on DPDK and
> understand the risk of conflict with some other code.
Agreed - there’s no harm in doing so.
My point was simply that for a
The script currently
handles Clang and GCC.
Fixes: 5c7d86948764 ("build: fix install on Windows")
Cc: sta...@dpdk.org
Signed-off-by: Nick Connolly
---
buildtools/symlink-drivers-solibs.py | 49
buildtools/symlink-drivers-solibs.sh | 13
config/meso
PDB (debuginfo) files can be quite large, do we want to install them?
The script copies will only copy the .pdb files if they have already
been installed into
lib/dpdk/pmds-*/. If they haven't, we'll just skip the step.
Whether they should be installed is a different question :-) Installing
y.
Signed-off-by: Dmitry Kozlyuk
Acked-by: Khoa To
Acked-by: Nick Connolly
build them. The script currently
handles Clang and GCC.
On Linux the functionality is unchanged, but could be replaced with the
python script once the required minimum version of meson is >= 0.55.0.
Fixes: 5c7d86948764 ("build: fix install on Windows")
Cc: sta...@dpdk.org
Signed-off-by: Ni
If anyone is attending SDC 2021, the DPDK community (and especially the
work to support Windows) gets a shout-out in one of the breakout
sessions tomorrow (Tuesday):
Can SPDK Deliver High Performance NVMe on Windows?
Nick Connolly, Chief Scientist MayaData / DataCore Software
https
diff --git a/lib/eal/windows/include/meson.build
b/lib/eal/windows/include/meson.build
index b3534b025f..875cc1cf0d 100644
--- a/lib/eal/windows/include/meson.build
+++ b/lib/eal/windows/include/meson.build
@@ -8,3 +8,7 @@ headers += files(
'rte_virt2phys.h',
'rte_windows.h',
What we can do:
1. Introduce `rte_queue.h` (name can be better) that is env-specific:
1.1. For Linux and FreeBSD it just includes
and renames a few macros that are used in headers to RTE_xxx.
1.2. For Windows it defines the same RTE_xxx macros in a way
compatible wi
Attaching to an NVMe disk on Windows using SPDK requires the
PCI class ID and device.bus fields. Decode the class ID from the PCI
device info strings if it is present and set device.bus.
Signed-off-by: Nick Connolly
---
drivers/bus/pci/windows/pci.c | 10 +-
1 file changed, 9 insertions
Enable the netuio driver for an NVMe storage controller on Windows.
Add the class ID 010802 and identify the device as
'netuio NVM Express Controller'.
Signed-off-by: Nick Connolly
---
windows/netuio/netuio.inf | 2 ++
1 file changed, 2 insertions(+)
diff --git a/windows/netuio/ne
Hi Tal,
Thanks for the comments.
+ /* Try and find PCI class ID */
+ for (cp = buf; !(cp[0] == 0 && cp[1] == 0); cp++)
How about
for (cp = buf; cp[0] || cp[1]; cp++)
That would be my preferred idiom, but the DPDK coding style (1.9.1) says
'do not use ! for tests unless it is a boo
On 26/01/2021 22:41, Thomas Monjalon wrote:
That's true. Comparisons should be explicit.
Thanks Thomas,
Nick
Attaching to an NVMe disk on Windows using SPDK requires the
PCI class ID and device.bus fields. Decode the class ID from the PCI
device info strings if it is present and set device.bus.
Signed-off-by: Nick Connolly
---
drivers/bus/pci/windows/pci.c | 15 ++-
1 file changed, 14
Attaching to an NVMe disk on Windows using SPDK requires the
PCI class ID and device.bus fields. Decode the class ID from the PCI
device info strings if it is present and set device.bus.
Signed-off-by: Nick Connolly
---
v3:
* Put version history at top - v2 mistakenly had it after the diffs
v2
Hi Tal,
+ /* Convert 4-digit class IDs to 6-digit format */
+ if (strspn(cp + 4, "0123456789abcdefABCDEF") == 4)
Maybe we can move this format string to a define in the header, something like
RTE_PCI_DRV_CLASSID_FMT?
I'll send out a v4 with a defi
Attaching to an NVMe disk on Windows using SPDK requires the
PCI class ID and device.bus fields. Decode the class ID from the PCI
device info strings if it is present and set device.bus.
Signed-off-by: Nick Connolly
---
drivers/bus/pci/windows/pci.c | 18 +-
1 file changed, 17
Attaching to an NVMe disk on Windows using SPDK requires the
PCI class ID and device.bus fields. Decode the class ID from the PCI
device info strings if it is present and set device.bus.
Signed-off-by: Nick Connolly
---
v5:
* Add missing version history
v4:
* Use #define to determine length of
Hi Harini,
As discussed - attaching zip file with images showing the NVMe device
being attached under netuio management and the output from the spdk
identify command.
Thanks,
Nick
On 25/01/2021 17:39, Nick Connolly wrote:
Enable the netuio driver for an NVMe storage controller on Windows
Rather than maintain dpdk internal dependencies on SPDK side, would it
be possible to use pkg-config?
Hi David,
Are the DPDK pkgconfig files intended to work for Windows builds?
I've had a quick look and as far as I can see the dependencies are
listed correctly,
but I was less convinced by
Rather than defining "rte_" versions of these functions, is it possible
just to provide the unprefixed definitions of them for internal use?
While this probably won't work for any functions used in public headers,
for any functions only used in C files, we can use meson to detect the
presence o
For any functions, such as strdup, which are not in a public header I would
suggest the following as a possible start point, based off what was done
for strlcpy.
* In DPDK (probably EAL), define an rte_strdup function for use as a
fallback.
* Inside the meson build scripts, use "cc.has_func
There seem to be two viable approaches to handling this:
1. Expect the platform to provide POSIX semantic (through an external
...
I'd prefer not to see this be a requirement of the platform. There have
been multiple attempts over the years to provide a POSIX surfaces
on Windows which arg
Enable the netuio driver for an NVMe storage controller on Windows.
Add the class ID 010802 and identify the device as
'netuio NVM Express Controller'.
Signed-off-by: Nick Connolly
---
v2:
* rebase to latest netuio.inf
windows/netuio/netuio.inf | 2 ++
1 file changed, 2 insertion
Attaching to an NVMe disk on Windows using SPDK requires the
PCI class ID and device.bus fields. Decode the class ID from the PCI
device info strings if it is present and set device.bus.
Signed-off-by: Nick Connolly
Acked-by: Tal Shnaiderman
---
v6:
* no changes - resending to resolve spurious
Allocating memory using rte_strdup() I'd use rte_free()
to release it. I guess it will fail badly.
So, I think that a different, more specific prefix is
required for POSIX wrappers.
Andrew: my understanding of Bruce's proposal is that the strdup() name
will now be kept (in this case through
Hi Dmitry,
+void
+rte_thread_sleep(unsigned int sec)
+{
+ return Sleep(MS_PER_S * sec);
+}
There's probably no benefit in returning the 'void' value - I'd suggest
just call Sleep().
Regards,
Nick
i40e
*/
#ifndef USER_EXPLICITLY_WANTS_WINDOWS_H
#undef min, max, ...
#endif
#define what's missing from Windows headers, e.g. IPPROTO_SCTP
+ Windows maintainers, Nick Connolly, and Jie Zhou to discuss.
In my opinion, there are long term maintenance i
Thanks Dmitry - will address and send v7.
On 28/02/2021 14:38, Dmitry Kozlyuk wrote:
2021-02-23 18:18, Nick Connolly:
Attaching to an NVMe disk on Windows using SPDK requires the
PCI class ID and device.bus fields. Decode the class ID from the PCI
device info strings if it is present and set
Attaching to an NVMe disk on Windows using SPDK requires the
PCI class ID and device.bus fields. Decode the class ID from the PCI
device info strings if it is present and set device.bus.
Signed-off-by: Nick Connolly
Acked-by: Tal Shnaiderman
Acked-by: Dmitry Kozlyuk
---
v7:
* Improve comments
Fixes: c08bd191b13d ("eal/windows: initialize hugepage info")
Cc: sta...@dpdk.org
Reported-by: Stephen Hemminger
Signed-off-by: Dmitry Kozlyuk
Acked-by: Nick Connolly
There's a meson issue with `cc.has_function()`:
https://github.com/mesonbuild/meson/issues/5628
What if we just define RTE_INTERNAL for librte_eal/windows/include/rte_os.h
(and other public headers if need be) to distinguish the case when it's used
from within DPDK?
It's a pragmatic solution t
Complete removal of non-standard dependencies in headers is within a grasp.
Then we can remove shims and include whatever needed.
Thoughts?
Sounds good. A couple of 'gotchas' that I've come across (but may not be
an issue for DPDK):
* Memory allocation / free that spans a dll boundary (see
+%vmxnet3.Description%=netuio_Device, PCI\VEN_15AD&DEV_07B0
Acked-by: Nick Connolly
PCI hardware IDs verified against:
https://devicehunt.com/view/type/pci/vendor/15AD/device/07B0
Calculation of usec value is incorrect - 'ticks' is not adjusted for
epoch, whereas 'sec' has been, also subtraction has mismatched units -
ticks in 100ns and sec * USEC_PER_SEC in usecs.
On 14/02/2021 01:20, Dmitry Kozlyuk wrote:
+ GetSystemTimePreciseAsFileTime(&ft);
+ ticks = (
Use PRIu32 for uint32_t (found by -Wformat with Clang on Windows).
Acked-by: Nick Connolly
Calculation of usec value is incorrect - 'ticks' is not adjusted for
epoch, whereas 'sec' has been, also subtraction has mismatched units -
ticks in 100ns and sec * USEC_PER_SEC in usecs.
Ignore - fixed in later version which I hadn't spotted.
Many PMDs use POSIX gettimeofday(). Add rte_time_get_us() function
to obtain current time with microsecond precision on all platforms.
Acked-by: Nick Connolly
Is posix_memalign() used more extensively in SPDK? In DPDK, it's 2 PMDs:
Yes, there are about 80 references. A lot are in ISA-L where they are
#defined to _aligned_malloc and can be ignored, but there still several
in the rest of the code.
* Sockets are unfortunately specified as using cl
DPDK supports a variety of platforms and toolsets and my experience with
SPDK suggests that we'll end up with compiler specific ifdef's.
I'd argue they are inevitable. Consider POSIX close(): if it's missing, what
would be a correct fallback? It depends on the execution environment (OS).
Str
Good catch - thanks Dmitry.
Ack-by: Nick Connolly
Hi Thomas,
I don't understand why there is no review.
Applied, thanks.
Reviewed by the team at Microsoft who were happy, but looks like a
formal 'Acked-by' didn't get sent.
Thanks,
Nick
meson guarantees this is portable, so this also allows us to remove a
is_windows switch.
Hi Gabriel,
On Windows, there are at least three different compilation options:
* MinGW-w64 with posix threads
* MinGW-w64 with win32 threads (different download)
* Clang without threads support
The
Threads is a dummy dependency for Clang. For MinGW without pthread it still
adds -pthread switch (and it comes to libdpdk.pc), but executable doesn't
require pthread library to run. I can imagine DPDK built by MinGW without
pthread be linked via pkg-config to an app built by MinGW with pthread,
Agreed. In my tests it's "-pthread", not "-lpthread", but still.
Agreed - I must have been distracted by the array of -l: arguments :-)
It's more like, in lib/librte_telemetry/meson.build:
if not is_windows
ext_deps += threads_dep
endif
It's not a big deal, b
Hi Bruce,
Would you have some time to take a look at this? It's a replacement for the
symlink-drivers-solibs.sh script for windows builds.
Thanks,
Nick
On 26/04/2021 11:07, Nick Connolly wrote:
The symlink-drivers-solibs.sh script was disabled as part of 'install'
for Window
I've reviewed it now and it looks good. Couldn't even find anything to
nit-pick in it! :-)
Thanks Bruce - appreciated :-)
Nick
t 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
ind
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..a29693
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 RT
On 30/10/2020 22:51, Tal Shnaiderman wrote:
Do we know why meson changed its behavior of lib file location in versions >
0.54?
Was the old behavior of keeping lib files in the matching output folders
incorrect?
I'm not sure why meson was changed, but without the fix subsequent
attempts to link
and 0.54.0. Only make the change
for >= 0.54.0, leaving the behaviour unchanged for earlier
versions.
Signed-off-by: Nick Connolly
Tested-by: Ranjit Menon
Acked-by: Ranjit Menon
---
v2:
* split out config/meson.build change
drivers/meson.build | 6 --
lib/meson.build | 6 --
2
and 0.54.0. Only make the change
for >= 0.54.0, leaving the behaviour unchanged for earlier
versions.
Signed-off-by: Nick Connolly
Tested-by: Ranjit Menon
Acked-by: Ranjit Menon
---
v2:
* split out config/meson.build change
drivers/meson.build | 6 --
lib/meson.build | 6 --
2
and 0.54.0. Only make the change
for >= 0.54.0, leaving the behaviour unchanged for earlier
versions.
Signed-off-by: Nick Connolly
Tested-by: Ranjit Menon
Acked-by: Ranjit Menon
---
v2:
* split out config/meson.build change
drivers/meson.build | 6 --
lib/meson.build | 6 --
2
Don't run symlink-drivers-solibs.sh as part of 'install' because
Windows doesn't support shell scripts.
Signed-off-by: Nick Connolly
Tested-by: Ranjit Menon
Acked-by: Ranjit Menon
---
config/meson.build | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
Missing / incorrect '--in-reply-to'. Please ignore - still learning the
process!
On 31/10/2020 06:43, Nick Connolly wrote:
Meson versions >= 0.54.0 include support for handling /implib
with msvc link. Specifying it explicitly causes failures when
linking against the dll. Test
Hi Khoa,
On 29/10/2020 21:19, Khoa To wrote:
-Original Message-
From: dev On Behalf Of Nick Connolly
Sent: Monday, October 19, 2020 2:59 AM
To: dev@dpdk.org
Subject: [EXTERNAL] [dpdk-dev] [RFC] pthread on Windows
The proposed changes are:
1. An EAL implementation of pthread with a
03/11/2020 22:34, Khoa To wrote:
+Dmitry, Harini
Hi Nick,
-Original Message-
From: Nick Connolly
Sent: Monday, November 2, 2020 3:17 AM
To: Khoa To ; dev@dpdk.org
Subject: Re: [EXTERNAL] [dpdk-dev] [RFC] pthread on Windows
Hi Khoa,
On 29/10/2020 21:19, Khoa To wrote:
-Original
Unfortunately, this change has broken the build for SPDK on Windows.
To use the DPDK libraries, an application needs to include the rte_*
header, which includes rte_os.h via rte_common.h. The definition of
ETOOMANYREFS clashes with the value used when building the SPDK on Windows.
The fundam
Thanks Tal.
On 19/11/2020 15:27, Tal Shnaiderman wrote:
Subject: Re: Windows: A fundamental issue (was eal/windows: definition for
ETOOMANYREFS errno)
External email: Use caution opening links or attachments
19/11/2020 14:21, Tal Shnaiderman:
Subject: Re: Windows: A fundamental issue (was e
Reviewed-by: Nick Connolly
On 19/11/2020 15:43, Tal Shnaiderman wrote:
This reverts commit c917b54b0c743c7a570a4d8df8954c61d8b818c4.
The definition of ETOOMANYREFS is reverted as it breaks build of
external applications already defining it.
Fixes: c917b54b0c ("eal/windows: add definiti
of INITGUID.
Fixes: b762221ac24f ("bus/pci: support Windows with bifurcated drivers")
Cc: tal...@mellanox.com
Signed-off-by: Nick Connolly
---
lib/librte_eal/windows/include/rte_windows.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lib/librte_eal/windows/include/rte_windo
I can't seem to reproduce the link error you've mentioned (I'm building
hello_world on master).
can you share more information on how to reproduce it? (MinGW version, build
env variables, build OS).
Thanks,
Tal.
Hi Tal,
Sure - latest MinGW-w64 (v8.0.0 I believe, but the versioning isn't
Build OS is Windows 10 2004
Hi Dmitry,
On 21/11/2020 20:47, Dmitry Kozlyuk wrote:
I disagree. Just because we have rte_windows.h to properly plug Windows SDK
in, other DPDK code doesn't need to care about these details. Unused GUIDs do
take some space in static libraries, but IMO it's a fair trade for ease of
development.
62221ac24f ("bus/pci: support Windows with bifurcated drivers")
Cc: tal...@mellanox.com
Signed-off-by: Nick Connolly
---
v2
* Fix commit message - add blank line, use present tense
lib/librte_eal/windows/include/rte_windows.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff
62221ac24f ("bus/pci: support Windows with bifurcated drivers")
Cc: sta...@dpdk.org
Signed-off-by: Nick Connolly
---
v2
* Change Cc to sta...@dpdk.org
v2
* Fix commit message - add blank line, use present tense
lib/librte_eal/windows/include/rte_windows.h | 2 +-
1 file changed, 1 ins
The root cause here is that rte_windows.h shouldn't be injecting
'missing' POSIX functionality
into the environment. The header is included indirectly in application
code via rte_os.h, but
deciding how to implement the 'missing' functionality should be the
applications responsibility.
There a
Errata: the definition is in rte_os.h rather than rte_windows.h
On 27/11/2020 10:05, Nick Connolly wrote:
The root cause here is that rte_windows.h shouldn't be injecting
'missing' POSIX functionality
into the environment. The header is included indirectly in
application co
sta...@dpdk.org
Signed-off-by: Nick Connolly
---
lib/librte_eal/windows/include/rte_os.h | 22 ++
1 file changed, 22 insertions(+)
diff --git a/lib/librte_eal/windows/include/rte_os.h
b/lib/librte_eal/windows/include/rte_os.h
index 569ed92d5..ea3fe60e5 100644
--- a/lib/lib
.
Signed-off-by: Nick Connolly
---
config/meson.build | 5 +
1 file changed, 5 insertions(+)
diff --git a/config/meson.build b/config/meson.build
index c02802c18..a3154e29c 100644
--- a/config/meson.build
+++ b/config/meson.build
@@ -279,6 +279,11 @@ if is_windows
U and NUMA node detection")
Cc: sta...@dpdk.org
Signed-off-by: Nick Connolly
---
lib/librte_eal/windows/eal_lcore.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/lib/librte_eal/windows/eal_lcore.c
b/lib/librte_eal/windows/eal_lcore.c
index d5ff721e0..d996b4f89 100644
--- a/lib/
I've created a patch for this and also for a couple of build warnings
that showed up doing
a similar test with clang.
On 27/11/2020 10:07, Nick Connolly wrote:
Errata: the definition is in rte_os.h rather than rte_windows.h
On 27/11/2020 10:05, Nick Connolly wrote:
The root cause here is
[Apologies if this is off-topic - just thought it might be of interest]
Thanks to the excellent work that has been done to get DPDK running on
Windows, it's now possible to build and run SPDK on Windows! (The SPDK
is a high performance user space storage stack based around the NVMe
protocol.
Looks good to me!
On 28/11/2020 21:11, Dmitry Kozlyuk wrote:
On Fri, 27 Nov 2020 12:07:11 +, Nick Connolly wrote:
[...]
+#ifdef __clang__
+#pragma clang diagnostic push
+#pragma clang diagnostic ignored "-Wformat-nonliteral"
+#endif
[...]
How about a more safe approach?
diff -
When building with clang (11.0,--buildtype=debug), eal_lcore.c
produces a -Wformat-nonliteral warning from the vfprintf call
in log_early.
Add __rte_format_printf annotation.
Fixes: b8a36b086625 ("eal/windows: improve CPU and NUMA node detection")
Cc: sta...@dpdk.org
Signed-of
es its own CRT without this issue.
[1]:
https://docs.microsoft.com/en-us/cpp/c-runtime-library/security-features-in-the-crt?view=msvc-160
Disable this by defining -D_CRT_SECURE_NO_WARNINGS.
Signed-off-by: Nick Connolly
---
v2:
* Adjust commit wording as per Dmitry Kozlyuk
Note: It is unclear exa
Copying sta...@dpdk.org - given that 20.11 has now been released I
assume this needs to be applied there as well.
On 07/12/2020 20:34, Thomas Monjalon wrote:
03/12/2020 01:02, Dmitry Kozlyuk:
On Sun, 29 Nov 2020 16:00:24 +, Nick Connolly wrote:
Microsoft CRT defines Windows-specific
There's also a blog post with some background at
https://www.linkedin.com/posts/nick-connolly-36276339_storage-is-evolving-activity-6743223532664184832-8Qzq
On 27/11/2020 20:13, Nick Connolly wrote:
[Apologies if this is off-topic - just thought it might be of interest]
Thanks to the exce
As part of the DPDK on Windows work, the following proposal has been put
together and we would welcome community feedback.
The heart of the issue is that, unlike Linux and FreeBSD, Windows does
not claim to be POSIX conformant: some functionality is missing, some is
present and some has differ
ENOSYS from
the kernel and fails the allocation.
The allocated socket should only be verified if check_numa() is true.
Fixes: 2a96c88be83e ("mem: ease init in a docker container")
Cc: nicolas.dich...@6wind.com
Cc: sta...@dpdk.org
Signed-off-by: Nick Connolly
---
lib/librte_eal/linux/eal_
Hi Nicolas,
Thanks for the quick response.
On 05/08/2020 14:42, Nicolas Dichtel wrote:
Le 05/08/2020 à 14:26, Nick Connolly a écrit :
Running dpdk-helloworld on Linux with lib numa present,
but no kernel support for NUMA (CONFIG_NUMA=n) causes
ret_service_init() to fail with EAL: error
On 05/08/2020 15:36, Nicolas Dichtel wrote:
Le 05/08/2020 à 16:20, Nick Connolly a écrit :
[snip]
Fixes: 2a96c88be83e ("mem: ease init in a docker container")
I'm wondering if the bug existed before this commit.
Before this commit, it was:
move_pages(getpid(),
On 05/08/2020 16:13, Nicolas Dichtel wrote:
Le 05/08/2020 à 16:53, Nick Connolly a écrit :
[snip]
+ if (check_numa()) {
+ ret = get_mempolicy(&cur_socket_id, NULL, 0, addr,
+ MPOL_F_NODE | MPOL_F_ADDR);
+ if (ret < 0) {
+ RTE_LOG(DEBUG, E
ENOSYS from
the kernel and fails the allocation.
The allocated socket should only be verified if check_numa() is true.
Fixes: 2a96c88be83e ("mem: ease init in a docker container")
Cc: nicolas.dich...@6wind.com
Cc: sta...@dpdk.org
Signed-off-by: Nick Connolly
---
v2:
* Remove unneces
ENOSYS from
the kernel and fails the allocation.
The allocated socket should only be verified if check_numa() is true.
Fixes: 2a96c88be83e ("mem: ease init in a docker container")
Cc: nicolas.dich...@6wind.com
Cc: sta...@dpdk.org
Signed-off-by: Nick Connolly
---
v2:
* Remove unneces
his occurs.
Do you know whether CONFIG_NUMA turns off all knowledge about the
hardware architecture? If it does, then I agree that the test for
rte_socket_count() serves no purpose and should be removed.
Many thanks,
Nick
On 17/09/2020 12:31, Burakov, Anatoly wrote:
On 05-Aug-20 1:26 PM, Nick
Hi Anatoly,
Thanks. My recollection is that all of the NUMA configuration flags
were set to 'n'.
Regards,
Nick
On 17/09/2020 13:57, Burakov, Anatoly wrote:
On 17-Sep-20 1:29 PM, Nick Connolly wrote:
Hi Anatoly,
Thanks for the response. You are asking a good question - here
Excellent - thanks - I'll amend the patch.
On 17/09/2020 15:07, Burakov, Anatoly wrote:
On 17-Sep-20 2:05 PM, Nick Connolly wrote:
Hi Anatoly,
Thanks. My recollection is that all of the NUMA configuration flags
were set to 'n'.
Regards,
Nick
On 17/09/2020 13:57, Burakov
Sure.
On 17/09/2020 15:18, Burakov, Anatoly wrote:
On 17-Sep-20 3:08 PM, Nick Connolly wrote:
Excellent - thanks - I'll amend the patch.
On 17/09/2020 15:07, Burakov, Anatoly wrote:
On 17-Sep-20 2:05 PM, Nick Connolly wrote:
Hi Anatoly,
Thanks. My recollection is that all of the
92 matches
Mail list logo
