DPDK patches and discussions
 help / color / mirror / Atom feed
* [dpdk-dev] [PATCH v2 0/4] build mempool on Windows
@ 2020-06-01 10:31 Fady Bader
  2020-06-01 10:31 ` [dpdk-dev] [PATCH v2 1/4] eal: disable function versioning " Fady Bader
                   ` (3 more replies)
  0 siblings, 4 replies; 15+ messages in thread
From: Fady Bader @ 2020-06-01 10:31 UTC (permalink / raw)
  To: dev
  Cc: thomas, tbashar, talshn, yohadt, dmitry.kozliuk,
	harini.ramakrishnan, ocardona, pallavi.kadam, ranjit.menon,
	olivier.matz, arybchenko, mdr, nhorman

Added changes in order to build mempool lib on windows.

Depends-on: patch-70497 ("ring: build on Windows")

v2:
    * Replace ifndef of tracepoints with symbol export from memory management
      patchset.

Fady Bader (4):
  eal: disable function versioning on Windows
  mempool: use generic memory management
  eal: export needed functions for mempool
  mempool: mempool build on Windows

 lib/librte_eal/include/rte_function_versioning.h |  4 ++++
 lib/librte_eal/rte_eal_exports.def               |  6 ++++++
 lib/librte_eal/rte_eal_version.map               |  3 +++
 lib/librte_mempool/rte_mempool.c                 | 21 ++++++++++-----------
 lib/meson.build                                  |  3 ++-
 5 files changed, 25 insertions(+), 12 deletions(-)

-- 
2.16.1.windows.4


^ permalink raw reply	[flat|nested] 15+ messages in thread

* [dpdk-dev] [PATCH v2 1/4] eal: disable function versioning on Windows
  2020-06-01 10:31 [dpdk-dev] [PATCH v2 0/4] build mempool on Windows Fady Bader
@ 2020-06-01 10:31 ` Fady Bader
  2020-06-01 19:55   ` Neil Horman
  2020-06-01 10:31 ` [dpdk-dev] [PATCH v2 2/4] mempool: use generic memory management Fady Bader
                   ` (2 subsequent siblings)
  3 siblings, 1 reply; 15+ messages in thread
From: Fady Bader @ 2020-06-01 10:31 UTC (permalink / raw)
  To: dev
  Cc: thomas, tbashar, talshn, yohadt, dmitry.kozliuk,
	harini.ramakrishnan, ocardona, pallavi.kadam, ranjit.menon,
	olivier.matz, arybchenko, mdr, nhorman

Function versioning is not needed on Windows, also the function versioning
implementation is not supported by Windows.
Function versioning was disabled on Windows.

Signed-off-by: Fady Bader <fady@mellanox.com>
---
 lib/librte_eal/include/rte_function_versioning.h | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/lib/librte_eal/include/rte_function_versioning.h b/lib/librte_eal/include/rte_function_versioning.h
index f588f2643..cee06602e 100644
--- a/lib/librte_eal/include/rte_function_versioning.h
+++ b/lib/librte_eal/include/rte_function_versioning.h
@@ -11,6 +11,10 @@
 #error Use of function versioning disabled, is "use_function_versioning=true" in meson.build?
 #endif
 
+#ifdef RTE_EXEC_ENV_WINDOWS
+#undef RTE_BUILD_SHARED_LIB
+#endif
+
 #ifdef RTE_BUILD_SHARED_LIB
 
 /*
-- 
2.16.1.windows.4


^ permalink raw reply	[flat|nested] 15+ messages in thread

* [dpdk-dev] [PATCH v2 2/4] mempool: use generic memory management
  2020-06-01 10:31 [dpdk-dev] [PATCH v2 0/4] build mempool on Windows Fady Bader
  2020-06-01 10:31 ` [dpdk-dev] [PATCH v2 1/4] eal: disable function versioning " Fady Bader
@ 2020-06-01 10:31 ` Fady Bader
  2020-06-01 19:59   ` Dmitry Kozlyuk
  2020-06-01 10:31 ` [dpdk-dev] [PATCH v2 3/4] eal: export needed functions for mempool Fady Bader
  2020-06-01 10:31 ` [dpdk-dev] [PATCH v2 4/4] mempool: mempool build on Windows Fady Bader
  3 siblings, 1 reply; 15+ messages in thread
From: Fady Bader @ 2020-06-01 10:31 UTC (permalink / raw)
  To: dev
  Cc: thomas, tbashar, talshn, yohadt, dmitry.kozliuk,
	harini.ramakrishnan, ocardona, pallavi.kadam, ranjit.menon,
	olivier.matz, arybchenko, mdr, nhorman

mempool used Unix memory management calls, which are not supported
on Windows.
Used generic memory management instead.

Signed-off-by: Fady Bader <fady@mellanox.com>
---
 lib/librte_mempool/rte_mempool.c | 21 ++++++++++-----------
 1 file changed, 10 insertions(+), 11 deletions(-)

diff --git a/lib/librte_mempool/rte_mempool.c b/lib/librte_mempool/rte_mempool.c
index 0bde995b5..c59f37a4e 100644
--- a/lib/librte_mempool/rte_mempool.c
+++ b/lib/librte_mempool/rte_mempool.c
@@ -12,7 +12,6 @@
 #include <inttypes.h>
 #include <errno.h>
 #include <sys/queue.h>
-#include <sys/mman.h>
 
 #include <rte_common.h>
 #include <rte_log.h>
@@ -148,7 +147,7 @@ get_min_page_size(int socket_id)
 
 	rte_memseg_list_walk(find_min_pagesz, &wa);
 
-	return wa.min == SIZE_MAX ? (size_t) getpagesize() : wa.min;
+	return wa.min == SIZE_MAX ? (size_t) rte_get_page_size() : wa.min;
 }
 
 
@@ -526,7 +525,7 @@ rte_mempool_get_page_size(struct rte_mempool *mp, size_t *pg_sz)
 	else if (rte_eal_has_hugepages() || alloc_in_ext_mem)
 		*pg_sz = get_min_page_size(mp->socket_id);
 	else
-		*pg_sz = getpagesize();
+		*pg_sz = rte_get_page_size();
 
 	rte_mempool_trace_get_page_size(mp, *pg_sz);
 	return 0;
@@ -686,7 +685,7 @@ get_anon_size(const struct rte_mempool *mp)
 	size_t min_chunk_size;
 	size_t align;
 
-	pg_sz = getpagesize();
+	pg_sz = rte_get_page_size();
 	pg_shift = rte_bsf32(pg_sz);
 	size = rte_mempool_ops_calc_mem_size(mp, mp->size, pg_shift,
 					     &min_chunk_size, &align);
@@ -710,7 +709,7 @@ rte_mempool_memchunk_anon_free(struct rte_mempool_memhdr *memhdr,
 	if (size < 0)
 		return;
 
-	munmap(opaque, size);
+	rte_mem_unmap(opaque, size);
 }
 
 /* populate the mempool with an anonymous mapping */
@@ -740,20 +739,20 @@ rte_mempool_populate_anon(struct rte_mempool *mp)
 	}
 
 	/* get chunk of virtually continuous memory */
-	addr = mmap(NULL, size, PROT_READ | PROT_WRITE,
-		MAP_SHARED | MAP_ANONYMOUS, -1, 0);
-	if (addr == MAP_FAILED) {
+	addr = rte_mem_map(NULL, size, RTE_PROT_READ | RTE_PROT_WRITE,
+		RTE_MAP_SHARED | RTE_MAP_ANONYMOUS, -1, 0);
+	if (addr == NULL) {
 		rte_errno = errno;
 		return 0;
 	}
 	/* can't use MMAP_LOCKED, it does not exist on BSD */
-	if (mlock(addr, size) < 0) {
+	if (rte_mem_lock(addr, size) < 0) {
 		rte_errno = errno;
-		munmap(addr, size);
+		rte_mem_unmap(addr, size);
 		return 0;
 	}
 
-	ret = rte_mempool_populate_virt(mp, addr, size, getpagesize(),
+	ret = rte_mempool_populate_virt(mp, addr, size, rte_get_page_size(),
 		rte_mempool_memchunk_anon_free, addr);
 	if (ret == 0) /* should not happen */
 		ret = -ENOBUFS;
-- 
2.16.1.windows.4


^ permalink raw reply	[flat|nested] 15+ messages in thread

* [dpdk-dev] [PATCH v2 3/4] eal: export needed functions for mempool
  2020-06-01 10:31 [dpdk-dev] [PATCH v2 0/4] build mempool on Windows Fady Bader
  2020-06-01 10:31 ` [dpdk-dev] [PATCH v2 1/4] eal: disable function versioning " Fady Bader
  2020-06-01 10:31 ` [dpdk-dev] [PATCH v2 2/4] mempool: use generic memory management Fady Bader
@ 2020-06-01 10:31 ` Fady Bader
  2020-06-01 10:31 ` [dpdk-dev] [PATCH v2 4/4] mempool: mempool build on Windows Fady Bader
  3 siblings, 0 replies; 15+ messages in thread
From: Fady Bader @ 2020-06-01 10:31 UTC (permalink / raw)
  To: dev
  Cc: thomas, tbashar, talshn, yohadt, dmitry.kozliuk,
	harini.ramakrishnan, ocardona, pallavi.kadam, ranjit.menon,
	olivier.matz, arybchenko, mdr, nhorman

Some eal functions were used by mempool lib but not exported on Windows.
The function was exported.

Signed-off-by: Fady Bader <fady@mellanox.com>
---
 lib/librte_eal/rte_eal_exports.def | 6 ++++++
 lib/librte_eal/rte_eal_version.map | 3 +++
 2 files changed, 9 insertions(+)

diff --git a/lib/librte_eal/rte_eal_exports.def b/lib/librte_eal/rte_eal_exports.def
index cbb6b8cfe..70d5e26b3 100644
--- a/lib/librte_eal/rte_eal_exports.def
+++ b/lib/librte_eal/rte_eal_exports.def
@@ -1,6 +1,11 @@
 EXPORTS
 	__rte_panic
+	__rte_trace_mem_per_thread_alloc
+	__rte_trace_point_emit_field
+	__rte_trace_point_register
 	per_lcore__rte_errno
+	per_lcore_trace_mem
+	per_lcore_trace_point_sz
 	rte_calloc
 	rte_calloc_socket
 	rte_eal_get_configuration
@@ -49,6 +54,7 @@ EXPORTS
 	rte_memzone_walk
 	rte_vlog
 	rte_realloc
+	rte_strscpy
 	rte_zmalloc
 	rte_zmalloc_socket
 
diff --git a/lib/librte_eal/rte_eal_version.map b/lib/librte_eal/rte_eal_version.map
index 8937bdfea..b96b21220 100644
--- a/lib/librte_eal/rte_eal_version.map
+++ b/lib/librte_eal/rte_eal_version.map
@@ -393,4 +393,7 @@ EXPERIMENTAL {
 	rte_mem_map;
 	rte_mem_unmap;
 	__emutls_v.per_lcore__rte_errno;
+	__emutls_v.per_lcore_trace_mem;
+	__emutls_v.per_lcore_trace_point_sz;
+	__rte_trace_mem_per_thread_alloc;
 };
-- 
2.16.1.windows.4


^ permalink raw reply	[flat|nested] 15+ messages in thread

* [dpdk-dev] [PATCH v2 4/4] mempool: mempool build on Windows
  2020-06-01 10:31 [dpdk-dev] [PATCH v2 0/4] build mempool on Windows Fady Bader
                   ` (2 preceding siblings ...)
  2020-06-01 10:31 ` [dpdk-dev] [PATCH v2 3/4] eal: export needed functions for mempool Fady Bader
@ 2020-06-01 10:31 ` Fady Bader
  2020-06-02  7:41   ` Andrew Rybchenko
  3 siblings, 1 reply; 15+ messages in thread
From: Fady Bader @ 2020-06-01 10:31 UTC (permalink / raw)
  To: dev
  Cc: thomas, tbashar, talshn, yohadt, dmitry.kozliuk,
	harini.ramakrishnan, ocardona, pallavi.kadam, ranjit.menon,
	olivier.matz, arybchenko, mdr, nhorman

Added mempool to supported libraries for Windows compilation.

Signed-off-by: Fady Bader <fady@mellanox.com>
---
 lib/meson.build | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/lib/meson.build b/lib/meson.build
index 30ed9e05e..c53732383 100644
--- a/lib/meson.build
+++ b/lib/meson.build
@@ -39,7 +39,8 @@ if is_windows
 	libraries = [
 		'kvargs',
 		'eal',
-		'ring'
+		'ring',
+		'mempool',
 		] # only supported libraries for windows
 endif
 
-- 
2.16.1.windows.4


^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [dpdk-dev] [PATCH v2 1/4] eal: disable function versioning on Windows
  2020-06-01 10:31 ` [dpdk-dev] [PATCH v2 1/4] eal: disable function versioning " Fady Bader
@ 2020-06-01 19:55   ` Neil Horman
  2020-06-01 21:46     ` [dpdk-dev] [EXTERNAL] " Omar Cardona
  0 siblings, 1 reply; 15+ messages in thread
From: Neil Horman @ 2020-06-01 19:55 UTC (permalink / raw)
  To: Fady Bader
  Cc: dev, thomas, tbashar, talshn, yohadt, dmitry.kozliuk,
	harini.ramakrishnan, ocardona, pallavi.kadam, ranjit.menon,
	olivier.matz, arybchenko, mdr

On Mon, Jun 01, 2020 at 01:31:36PM +0300, Fady Bader wrote:
> Function versioning is not needed on Windows, also the function versioning
> implementation is not supported by Windows.
> Function versioning was disabled on Windows.
> 
I get that windows doesn't seem to support symbol level versioning, but I'm not
sure its reasonable to say that its not needed, unless we never have any
intention of building dpdk on windows using a DSO model.  The below definately
solves the immediate problem, but if we plan to support windows with dynamic
library builds, this just kicks the can down the road.

Do we know if we have future plans of supporting dlls on windows in the future?

Neil

> Signed-off-by: Fady Bader <fady@mellanox.com>
> ---
>  lib/librte_eal/include/rte_function_versioning.h | 4 ++++
>  1 file changed, 4 insertions(+)
> 
> diff --git a/lib/librte_eal/include/rte_function_versioning.h b/lib/librte_eal/include/rte_function_versioning.h
> index f588f2643..cee06602e 100644
> --- a/lib/librte_eal/include/rte_function_versioning.h
> +++ b/lib/librte_eal/include/rte_function_versioning.h
> @@ -11,6 +11,10 @@
>  #error Use of function versioning disabled, is "use_function_versioning=true" in meson.build?
>  #endif
>  
> +#ifdef RTE_EXEC_ENV_WINDOWS
> +#undef RTE_BUILD_SHARED_LIB
> +#endif
> +
>  #ifdef RTE_BUILD_SHARED_LIB
>  
>  /*
> -- 
> 2.16.1.windows.4
> 
> 

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [dpdk-dev] [PATCH v2 2/4] mempool: use generic memory management
  2020-06-01 10:31 ` [dpdk-dev] [PATCH v2 2/4] mempool: use generic memory management Fady Bader
@ 2020-06-01 19:59   ` Dmitry Kozlyuk
  2020-06-01 20:47     ` Ranjit Menon
  2020-06-01 21:14     ` Thomas Monjalon
  0 siblings, 2 replies; 15+ messages in thread
From: Dmitry Kozlyuk @ 2020-06-01 19:59 UTC (permalink / raw)
  To: Fady Bader
  Cc: dev, thomas, tbashar, talshn, yohadt, harini.ramakrishnan,
	ocardona, pallavi.kadam, ranjit.menon, olivier.matz, arybchenko,
	mdr, nhorman

On Mon,  1 Jun 2020 13:31:37 +0300
Fady Bader <fady@mellanox.com> wrote:

[snip]
>  /* populate the mempool with an anonymous mapping */
> @@ -740,20 +739,20 @@ rte_mempool_populate_anon(struct rte_mempool *mp)
>  	}
>  
>  	/* get chunk of virtually continuous memory */
> -	addr = mmap(NULL, size, PROT_READ | PROT_WRITE,
> -		MAP_SHARED | MAP_ANONYMOUS, -1, 0);
> -	if (addr == MAP_FAILED) {
> +	addr = rte_mem_map(NULL, size, RTE_PROT_READ | RTE_PROT_WRITE,
> +		RTE_MAP_SHARED | RTE_MAP_ANONYMOUS, -1, 0);
> +	if (addr == NULL) {
>  		rte_errno = errno;

rte_mem_map() sets rte_errno, on Windows using errno here is invalid.

>  		return 0;
>  	}
>  	/* can't use MMAP_LOCKED, it does not exist on BSD */
> -	if (mlock(addr, size) < 0) {
> +	if (rte_mem_lock(addr, size) < 0) {
>  		rte_errno = errno;

Same as above.

[snip]

Two more things:

1. What do you think about changing rte_ to rte_eal_ prefix for memory
management wrappers in MM series as Andrew Rybchenko suggested for v1? Since
the functions are DPDK-internal, this sounds reasonable to me.

2. Please use --in-reply-to for v2 and on.

-- 
Dmitry Kozlyuk

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [dpdk-dev] [PATCH v2 2/4] mempool: use generic memory management
  2020-06-01 19:59   ` Dmitry Kozlyuk
@ 2020-06-01 20:47     ` Ranjit Menon
  2020-06-01 21:14     ` Thomas Monjalon
  1 sibling, 0 replies; 15+ messages in thread
From: Ranjit Menon @ 2020-06-01 20:47 UTC (permalink / raw)
  To: Dmitry Kozlyuk, Fady Bader
  Cc: dev, thomas, tbashar, talshn, yohadt, harini.ramakrishnan,
	ocardona, pallavi.kadam, olivier.matz, arybchenko, mdr, nhorman

On 6/1/2020 12:59 PM, Dmitry Kozlyuk wrote:
> On Mon,  1 Jun 2020 13:31:37 +0300
> Fady Bader <fady@mellanox.com> wrote:
>
> [snip]
>>   /* populate the mempool with an anonymous mapping */
>> @@ -740,20 +739,20 @@ rte_mempool_populate_anon(struct rte_mempool *mp)
>>   	}
>>   
>>   	/* get chunk of virtually continuous memory */
>> -	addr = mmap(NULL, size, PROT_READ | PROT_WRITE,
>> -		MAP_SHARED | MAP_ANONYMOUS, -1, 0);
>> -	if (addr == MAP_FAILED) {
>> +	addr = rte_mem_map(NULL, size, RTE_PROT_READ | RTE_PROT_WRITE,
>> +		RTE_MAP_SHARED | RTE_MAP_ANONYMOUS, -1, 0);
>> +	if (addr == NULL) {
>>   		rte_errno = errno;
> rte_mem_map() sets rte_errno, on Windows using errno here is invalid.
>
>>   		return 0;
>>   	}
>>   	/* can't use MMAP_LOCKED, it does not exist on BSD */
>> -	if (mlock(addr, size) < 0) {
>> +	if (rte_mem_lock(addr, size) < 0) {
>>   		rte_errno = errno;
> Same as above.
>
> [snip]
>
> Two more things:
>
> 1. What do you think about changing rte_ to rte_eal_ prefix for memory
> management wrappers in MM series as Andrew Rybchenko suggested for v1? Since
> the functions are DPDK-internal, this sounds reasonable to me.

I fully support this.

ranjit m.



^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [dpdk-dev] [PATCH v2 2/4] mempool: use generic memory management
  2020-06-01 19:59   ` Dmitry Kozlyuk
  2020-06-01 20:47     ` Ranjit Menon
@ 2020-06-01 21:14     ` Thomas Monjalon
  2020-06-02  7:40       ` Andrew Rybchenko
  1 sibling, 1 reply; 15+ messages in thread
From: Thomas Monjalon @ 2020-06-01 21:14 UTC (permalink / raw)
  To: Dmitry Kozlyuk
  Cc: Fady Bader, dev, tbashar, talshn, yohadt, harini.ramakrishnan,
	ocardona, pallavi.kadam, ranjit.menon, olivier.matz, arybchenko,
	mdr, nhorman

01/06/2020 21:59, Dmitry Kozlyuk:
> 1. What do you think about changing rte_ to rte_eal_ prefix for memory
> management wrappers in MM series as Andrew Rybchenko suggested for v1? Since
> the functions are DPDK-internal, this sounds reasonable to me.

For lib-internal function, the prefix should not start with rte_.
For exported function (even if internal), the prefix should be rte_[component]_.
For memory related functions, rte_mem_ is better than rte_eal_.




^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [dpdk-dev] [EXTERNAL] Re: [PATCH v2 1/4] eal: disable function versioning on Windows
  2020-06-01 19:55   ` Neil Horman
@ 2020-06-01 21:46     ` Omar Cardona
  2020-06-02 10:27       ` Neil Horman
  0 siblings, 1 reply; 15+ messages in thread
From: Omar Cardona @ 2020-06-01 21:46 UTC (permalink / raw)
  To: Neil Horman, Fady Bader
  Cc: dev, thomas, tbashar, talshn, yohadt, dmitry.kozliuk,
	Harini Ramakrishnan, pallavi.kadam, ranjit.menon, olivier.matz,
	arybchenko, mdr

>> Do we know if we have future plans of supporting dlls on windows in the future?
	- Hi Neil, yes this is of interest to us (Windows).  
	- Specifically to aid in non-disruptive granular servicing/updating.
	- Our primary scenario Userspace VMSwitch is biased towards shared libraries for production servicing


-----Original Message-----
From: Neil Horman <nhorman@tuxdriver.com> 
Sent: Monday, June 1, 2020 12:56 PM
To: Fady Bader <fady@mellanox.com>
Cc: dev@dpdk.org; thomas@monjalon.net; tbashar@mellanox.com; talshn@mellanox.com; yohadt@mellanox.com; dmitry.kozliuk@gmail.com; Harini Ramakrishnan <Harini.Ramakrishnan@microsoft.com>; Omar Cardona <ocardona@microsoft.com>; pallavi.kadam@intel.com; ranjit.menon@intel.com; olivier.matz@6wind.com; arybchenko@solarflare.com; mdr@ashroe.eu
Subject: [EXTERNAL] Re: [PATCH v2 1/4] eal: disable function versioning on Windows

On Mon, Jun 01, 2020 at 01:31:36PM +0300, Fady Bader wrote:
> Function versioning is not needed on Windows, also the function 
> versioning implementation is not supported by Windows.
> Function versioning was disabled on Windows.
> 
I get that windows doesn't seem to support symbol level versioning, but I'm not sure its reasonable to say that its not needed, unless we never have any intention of building dpdk on windows using a DSO model.  The below definately solves the immediate problem, but if we plan to support windows with dynamic library builds, this just kicks the can down the road.

Do we know if we have future plans of supporting dlls on windows in the future?

Neil

> Signed-off-by: Fady Bader <fady@mellanox.com>
> ---
>  lib/librte_eal/include/rte_function_versioning.h | 4 ++++
>  1 file changed, 4 insertions(+)
> 
> diff --git a/lib/librte_eal/include/rte_function_versioning.h 
> b/lib/librte_eal/include/rte_function_versioning.h
> index f588f2643..cee06602e 100644
> --- a/lib/librte_eal/include/rte_function_versioning.h
> +++ b/lib/librte_eal/include/rte_function_versioning.h
> @@ -11,6 +11,10 @@
>  #error Use of function versioning disabled, is "use_function_versioning=true" in meson.build?
>  #endif
>  
> +#ifdef RTE_EXEC_ENV_WINDOWS
> +#undef RTE_BUILD_SHARED_LIB
> +#endif
> +
>  #ifdef RTE_BUILD_SHARED_LIB
>  
>  /*
> --
> 2.16.1.windows.4
> 
> 

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [dpdk-dev] [PATCH v2 2/4] mempool: use generic memory management
  2020-06-01 21:14     ` Thomas Monjalon
@ 2020-06-02  7:40       ` Andrew Rybchenko
  0 siblings, 0 replies; 15+ messages in thread
From: Andrew Rybchenko @ 2020-06-02  7:40 UTC (permalink / raw)
  To: Thomas Monjalon, Dmitry Kozlyuk
  Cc: Fady Bader, dev, tbashar, talshn, yohadt, harini.ramakrishnan,
	ocardona, pallavi.kadam, ranjit.menon, olivier.matz, mdr,
	nhorman

On 6/2/20 12:14 AM, Thomas Monjalon wrote:
> 01/06/2020 21:59, Dmitry Kozlyuk:
>> 1. What do you think about changing rte_ to rte_eal_ prefix for memory
>> management wrappers in MM series as Andrew Rybchenko suggested for v1? Since
>> the functions are DPDK-internal, this sounds reasonable to me.
> 
> For lib-internal function, the prefix should not start with rte_.
> For exported function (even if internal), the prefix should be rte_[component]_.
> For memory related functions, rte_mem_ is better than rte_eal_.

Yes, I agree.



^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [dpdk-dev] [PATCH v2 4/4] mempool: mempool build on Windows
  2020-06-01 10:31 ` [dpdk-dev] [PATCH v2 4/4] mempool: mempool build on Windows Fady Bader
@ 2020-06-02  7:41   ` Andrew Rybchenko
  0 siblings, 0 replies; 15+ messages in thread
From: Andrew Rybchenko @ 2020-06-02  7:41 UTC (permalink / raw)
  To: Fady Bader, dev
  Cc: thomas, tbashar, talshn, yohadt, dmitry.kozliuk,
	harini.ramakrishnan, ocardona, pallavi.kadam, ranjit.menon,
	olivier.matz, mdr, nhorman

On 6/1/20 1:31 PM, Fady Bader wrote:
> Added mempool to supported libraries for Windows compilation.
> 
> Signed-off-by: Fady Bader <fady@mellanox.com>
> ---
>  lib/meson.build | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/lib/meson.build b/lib/meson.build
> index 30ed9e05e..c53732383 100644
> --- a/lib/meson.build
> +++ b/lib/meson.build
> @@ -39,7 +39,8 @@ if is_windows
>  	libraries = [
>  		'kvargs',
>  		'eal',
> -		'ring'
> +		'ring',

It should be a comma after 'ring' in ring patchset.

> +		'mempool',
>  		] # only supported libraries for windows
>  endif
>  
> 


^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [dpdk-dev] [EXTERNAL] Re: [PATCH v2 1/4] eal: disable function versioning on Windows
  2020-06-01 21:46     ` [dpdk-dev] [EXTERNAL] " Omar Cardona
@ 2020-06-02 10:27       ` Neil Horman
  2020-06-02 10:40         ` Thomas Monjalon
  0 siblings, 1 reply; 15+ messages in thread
From: Neil Horman @ 2020-06-02 10:27 UTC (permalink / raw)
  To: Omar Cardona
  Cc: Fady Bader, dev, thomas, tbashar, talshn, yohadt, dmitry.kozliuk,
	Harini Ramakrishnan, pallavi.kadam, ranjit.menon, olivier.matz,
	arybchenko, mdr

On Mon, Jun 01, 2020 at 09:46:18PM +0000, Omar Cardona wrote:
> >> Do we know if we have future plans of supporting dlls on windows in the future?
> 	- Hi Neil, yes this is of interest to us (Windows).  
> 	- Specifically to aid in non-disruptive granular servicing/updating.
> 	- Our primary scenario Userspace VMSwitch is biased towards shared libraries for production servicing
> 
Ok, do you have recommendations on how to provide backwards compatibility
between dpdk versions?  From what I read the most direct solution would be
per-application dll bundling (which seems to me to defeat the purpose of
creating a dll, but if its the only solution, perhaps thats all we have to work
with).  Is there a better solution?

If not, then I would suggest that, instead of disabling shared libraries on
Windows, as we do below, we allow it, and redefine VERSION_SYMBOL[_EXPERIMENTAL]
to do nothing, and implement BIND_DEFAULT_SYMBOL to act like MAP_STATIC_SYMBOL
by aliasing the supplied symbol name to the provided export name.  I think msvc
supports aliasing, correct?
Neil

> 
> -----Original Message-----
> From: Neil Horman <nhorman@tuxdriver.com> 
> Sent: Monday, June 1, 2020 12:56 PM
> To: Fady Bader <fady@mellanox.com>
> Cc: dev@dpdk.org; thomas@monjalon.net; tbashar@mellanox.com; talshn@mellanox.com; yohadt@mellanox.com; dmitry.kozliuk@gmail.com; Harini Ramakrishnan <Harini.Ramakrishnan@microsoft.com>; Omar Cardona <ocardona@microsoft.com>; pallavi.kadam@intel.com; ranjit.menon@intel.com; olivier.matz@6wind.com; arybchenko@solarflare.com; mdr@ashroe.eu
> Subject: [EXTERNAL] Re: [PATCH v2 1/4] eal: disable function versioning on Windows
> 
> On Mon, Jun 01, 2020 at 01:31:36PM +0300, Fady Bader wrote:
> > Function versioning is not needed on Windows, also the function 
> > versioning implementation is not supported by Windows.
> > Function versioning was disabled on Windows.
> > 
> I get that windows doesn't seem to support symbol level versioning, but I'm not sure its reasonable to say that its not needed, unless we never have any intention of building dpdk on windows using a DSO model.  The below definately solves the immediate problem, but if we plan to support windows with dynamic library builds, this just kicks the can down the road.
> 
> Do we know if we have future plans of supporting dlls on windows in the future?
> 
> Neil
> 
> > Signed-off-by: Fady Bader <fady@mellanox.com>
> > ---
> >  lib/librte_eal/include/rte_function_versioning.h | 4 ++++
> >  1 file changed, 4 insertions(+)
> > 
> > diff --git a/lib/librte_eal/include/rte_function_versioning.h 
> > b/lib/librte_eal/include/rte_function_versioning.h
> > index f588f2643..cee06602e 100644
> > --- a/lib/librte_eal/include/rte_function_versioning.h
> > +++ b/lib/librte_eal/include/rte_function_versioning.h
> > @@ -11,6 +11,10 @@
> >  #error Use of function versioning disabled, is "use_function_versioning=true" in meson.build?
> >  #endif
> >  
> > +#ifdef RTE_EXEC_ENV_WINDOWS
> > +#undef RTE_BUILD_SHARED_LIB
> > +#endif
> > +
> >  #ifdef RTE_BUILD_SHARED_LIB
> >  
> >  /*
> > --
> > 2.16.1.windows.4
> > 
> > 
> 

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [dpdk-dev] [EXTERNAL] Re: [PATCH v2 1/4] eal: disable function versioning on Windows
  2020-06-02 10:27       ` Neil Horman
@ 2020-06-02 10:40         ` Thomas Monjalon
  2020-06-11 10:09           ` Kinsella, Ray
  0 siblings, 1 reply; 15+ messages in thread
From: Thomas Monjalon @ 2020-06-02 10:40 UTC (permalink / raw)
  To: Omar Cardona, Neil Horman
  Cc: Fady Bader, dev, tbashar, talshn, yohadt, dmitry.kozliuk,
	Harini Ramakrishnan, pallavi.kadam, ranjit.menon, olivier.matz,
	arybchenko, mdr

02/06/2020 12:27, Neil Horman:
> On Mon, Jun 01, 2020 at 09:46:18PM +0000, Omar Cardona wrote:
> > >> Do we know if we have future plans of supporting dlls on windows in the future?
> > 	- Hi Neil, yes this is of interest to us (Windows).  
> > 	- Specifically to aid in non-disruptive granular servicing/updating.
> > 	- Our primary scenario Userspace VMSwitch is biased towards shared libraries for production servicing
> > 
> Ok, do you have recommendations on how to provide backwards compatibility
> between dpdk versions?  From what I read the most direct solution would be
> per-application dll bundling (which seems to me to defeat the purpose of
> creating a dll, but if its the only solution, perhaps thats all we have to work
> with).  Is there a better solution?
> 
> If not, then I would suggest that, instead of disabling shared libraries on
> Windows, as we do below, we allow it, and redefine VERSION_SYMBOL[_EXPERIMENTAL]
> to do nothing, and implement BIND_DEFAULT_SYMBOL to act like MAP_STATIC_SYMBOL
> by aliasing the supplied symbol name to the provided export name.  I think msvc
> supports aliasing, correct?

We don't use msvc, but clang and MinGW.



^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [dpdk-dev] [EXTERNAL] Re: [PATCH v2 1/4] eal: disable function versioning on Windows
  2020-06-02 10:40         ` Thomas Monjalon
@ 2020-06-11 10:09           ` Kinsella, Ray
  0 siblings, 0 replies; 15+ messages in thread
From: Kinsella, Ray @ 2020-06-11 10:09 UTC (permalink / raw)
  To: Thomas Monjalon, Omar Cardona, Neil Horman
  Cc: Fady Bader, dev, tbashar, talshn, yohadt, dmitry.kozliuk,
	Harini Ramakrishnan, pallavi.kadam, ranjit.menon, olivier.matz,
	arybchenko

So apologies for resurrecting an old thread - I did want to chime on this.

From a past life as a Windows Programmer, I would say that shared libraries model on Windows is not as strong as on Linux/Unix.
Libraries on Windows are typically packaged and distributed along with the applications, not usually at a system level as in Linux/Unix.

That said - I strongly agree with Omar - that does not mean that stable ABI's should not be goal on Windows.
This does not diminish the value of enabling Windows applications to seamless upgrade their DPDK, at an application level.

So I don't have a problem with disabling function-level versioning as an interim measure, until we figure out the best mechanism.
What I would suggest is that we aim to get this sort for the v22 ABI in the 21.11 release.
And that we clearly indicate in v21 in 20.11 that Windows is not yet covered in the ABI policy.

Make sense?

Ray K

On 02/06/2020 11:40, Thomas Monjalon wrote:
> 02/06/2020 12:27, Neil Horman:
>> On Mon, Jun 01, 2020 at 09:46:18PM +0000, Omar Cardona wrote:
>>>>> Do we know if we have future plans of supporting dlls on windows in the future?
>>> 	- Hi Neil, yes this is of interest to us (Windows).  
>>> 	- Specifically to aid in non-disruptive granular servicing/updating.
>>> 	- Our primary scenario Userspace VMSwitch is biased towards shared libraries for production servicing
>>>
>> Ok, do you have recommendations on how to provide backwards compatibility
>> between dpdk versions?  From what I read the most direct solution would be
>> per-application dll bundling (which seems to me to defeat the purpose of
>> creating a dll, but if its the only solution, perhaps thats all we have to work
>> with).  Is there a better solution?
>>
>> If not, then I would suggest that, instead of disabling shared libraries on
>> Windows, as we do below, we allow it, and redefine VERSION_SYMBOL[_EXPERIMENTAL]
>> to do nothing, and implement BIND_DEFAULT_SYMBOL to act like MAP_STATIC_SYMBOL
>> by aliasing the supplied symbol name to the provided export name.  I think msvc
>> supports aliasing, correct?
> We don't use msvc, but clang and MinGW.
>
>


^ permalink raw reply	[flat|nested] 15+ messages in thread

end of thread, other threads:[~2020-06-11 10:09 UTC | newest]

Thread overview: 15+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-06-01 10:31 [dpdk-dev] [PATCH v2 0/4] build mempool on Windows Fady Bader
2020-06-01 10:31 ` [dpdk-dev] [PATCH v2 1/4] eal: disable function versioning " Fady Bader
2020-06-01 19:55   ` Neil Horman
2020-06-01 21:46     ` [dpdk-dev] [EXTERNAL] " Omar Cardona
2020-06-02 10:27       ` Neil Horman
2020-06-02 10:40         ` Thomas Monjalon
2020-06-11 10:09           ` Kinsella, Ray
2020-06-01 10:31 ` [dpdk-dev] [PATCH v2 2/4] mempool: use generic memory management Fady Bader
2020-06-01 19:59   ` Dmitry Kozlyuk
2020-06-01 20:47     ` Ranjit Menon
2020-06-01 21:14     ` Thomas Monjalon
2020-06-02  7:40       ` Andrew Rybchenko
2020-06-01 10:31 ` [dpdk-dev] [PATCH v2 3/4] eal: export needed functions for mempool Fady Bader
2020-06-01 10:31 ` [dpdk-dev] [PATCH v2 4/4] mempool: mempool build on Windows Fady Bader
2020-06-02  7:41   ` Andrew Rybchenko

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).