[dpdk-dev] [Bug] Static constructors considered evil

[dpdk-dev] [Bug] Static constructors considered evil

[Jean Tourrilhes]

	Hi,

	Expecting static constructors to match between the primary and
the secondary is ill advised and putting yourself at the mercy of the
linker magic. In this case, both primary and secondary were compiled
using the same DPDK directory and exact same libdpdk.a.

Config :
------
CONFIG_RTE_LIBRTE_HASH=y
CONFIG_RTE_LIBRTE_LPM=y
CONFIG_RTE_LIBRTE_ACL=y
CONFIG_RTE_LIBRTE_DISTRIBUTOR=y
CONFIG_RTE_LIBRTE_REORDER=y

Primary :
-------
EAL: Registered tailq: RTE_ACL
EAL: Registered tailq: RTE_HASH
EAL: Registered tailq: RTE_FBK_HASH
EAL: Registered tailq: RTE_MEMPOOL
EAL: Registered tailq: RTE_RING
EAL: Registered tailq: VFIO_RESOURCE_LIST
EAL: Registered tailq: UIO_RESOURCE_LIST
Tailq 0: qname:<RTE_ACL>, tqh_first:(nil), tqh_last:0x7feffffff41c
Tailq 1: qname:<RTE_HASH>, tqh_first:(nil), tqh_last:0x7feffffff44c
Tailq 2: qname:<RTE_FBK_HASH>, tqh_first:(nil), tqh_last:0x7feffffff47c
Tailq 3: qname:<RTE_MEMPOOL>, tqh_first:(nil), tqh_last:0x7feffffff4ac
Tailq 4: qname:<RTE_RING>, tqh_first:(nil), tqh_last:0x7feffffff4dc
Tailq 5: qname:<VFIO_RESOURCE_LIST>, tqh_first:(nil), tqh_last:0x7feffffff50c
Tailq 6: qname:<UIO_RESOURCE_LIST>, tqh_first:(nil), tqh_last:0x7feffffff53c
Tailq 7: qname:<>, tqh_first:(nil), tqh_last:(nil)
Tailq 8: qname:<>, tqh_first:(nil), tqh_last:(nil)
Tailq 9: qname:<>, tqh_first:(nil), tqh_last:(nil)

Secondary :
---------
EAL: Registered tailq: RTE_LPM
EAL: Registered tailq: RTE_LPM6
EAL: Registered tailq: RTE_HASH
EAL: Registered tailq: RTE_FBK_HASH
EAL: Registered tailq: RTE_ACL
EAL: Registered tailq: RTE_REORDER
EAL: Registered tailq: VFIO_RESOURCE_LIST
EAL: Registered tailq: UIO_RESOURCE_LIST
EAL: Registered tailq: RTE_DISTRIBUTOR
EAL: Registered tailq: RTE_MEMPOOL
EAL: Registered tailq: RTE_RING
EAL: Cannot initialize tailq: RTE_LPM
Tailq 0: qname:<RTE_ACL>, tqh_first:(nil), tqh_last:0x7feffffff41c
Tailq 1: qname:<RTE_HASH>, tqh_first:0x7ff0004c62c0, tqh_last:0x7ff0004c62c0
Tailq 2: qname:<RTE_FBK_HASH>, tqh_first:(nil), tqh_last:0x7feffffff47c
Tailq 3: qname:<RTE_MEMPOOL>, tqh_first:0x7ff0004a81c0, tqh_last:0x7ff0004a8040
Tailq 4: qname:<RTE_RING>, tqh_first:0x7ff0004a8140, tqh_last:0x7ff0004c6340
Tailq 5: qname:<VFIO_RESOURCE_LIST>, tqh_first:0x7ff0005fee80, tqh_last:0x7ff00052be80
Tailq 6: qname:<UIO_RESOURCE_LIST>, tqh_first:(nil), tqh_last:0x7feffffff53c
Tailq 7: qname:<>, tqh_first:(nil), tqh_last:(nil)
Tailq 8: qname:<>, tqh_first:(nil), tqh_last:(nil)
Tailq 9: qname:<>, tqh_first:(nil), tqh_last:(nil)
[...]
PANIC in rte_eal_init():
Cannot init tail queues for objects

	Obviously not happy...
	Any advices ?

	Jean

[dpdk-dev] [PATCH 1/1] eal: Don't fail secondary if primary is missing tailqs

[Jean Tourrilhes]

 lib/librte_eal/common/eal_common_tailqs.c | 15 ++++++++++++---
 1 file changed, 12 insertions(+), 3 deletions(-)

diff --git a/lib/librte_eal/common/eal_common_tailqs.c b/lib/librte_eal/common/eal_common_tailqs.c
index bb08ec8..6960d06 100644
--- a/lib/librte_eal/common/eal_common_tailqs.c
+++ b/lib/librte_eal/common/eal_common_tailqs.c
@@ -143,6 +143,8 @@ rte_eal_tailq_update(struct rte_tailq_elem *t)
 		t->head = rte_eal_tailq_create(t->name);
 	} else {
 		t->head = rte_eal_tailq_lookup(t->name);
+		if (t->head != NULL)
+			rte_tailqs_count++;
 	}
 }
 
@@ -188,9 +190,16 @@ rte_eal_tailqs_init(void)
 		if (t->head == NULL) {
 			RTE_LOG(ERR, EAL,
 				"Cannot initialize tailq: %s\n", t->name);
-			/* no need to TAILQ_REMOVE, we are going to panic in
-			 * rte_eal_init() */
-			goto fail;
+			if (rte_eal_process_type() == RTE_PROC_PRIMARY) {
+				/* no need to TAILQ_REMOVE, we are going
+				 * to panic in rte_eal_init() */
+				goto fail;
+			} else {
+				/* This means our list of constructor is
+				 * no the same as primary. Just remove
+				 * that missing tailq and continue */
+				TAILQ_REMOVE(&rte_tailq_elem_head, t, next);
+			}
 		}
 	}
 

Re: [dpdk-dev] [PATCH 1/1] eal: Don't fail secondary if primary is missing tailqs

[Sergio Gonzalez Monroy]

Hi Jean,

As with your other patch, commit title needs fixing and also missing 
Signed-off-by line.

On 22/09/2016 22:17, Jean Tourrilhes wrote:
>   lib/librte_eal/common/eal_common_tailqs.c | 15 ++++++++++++---
>   1 file changed, 12 insertions(+), 3 deletions(-)
>
> diff --git a/lib/librte_eal/common/eal_common_tailqs.c b/lib/librte_eal/common/eal_common_tailqs.c
> index bb08ec8..6960d06 100644
> --- a/lib/librte_eal/common/eal_common_tailqs.c
> +++ b/lib/librte_eal/common/eal_common_tailqs.c
> @@ -143,6 +143,8 @@ rte_eal_tailq_update(struct rte_tailq_elem *t)
>   		t->head = rte_eal_tailq_create(t->name);
>   	} else {
>   		t->head = rte_eal_tailq_lookup(t->name);
> +		if (t->head != NULL)
> +			rte_tailqs_count++;
>   	}
>   }
>   
> @@ -188,9 +190,16 @@ rte_eal_tailqs_init(void)
>   		if (t->head == NULL) {
>   			RTE_LOG(ERR, EAL,
>   				"Cannot initialize tailq: %s\n", t->name);
> -			/* no need to TAILQ_REMOVE, we are going to panic in
> -			 * rte_eal_init() */
> -			goto fail;
> +			if (rte_eal_process_type() == RTE_PROC_PRIMARY) {
> +				/* no need to TAILQ_REMOVE, we are going
> +				 * to panic in rte_eal_init() */
> +				goto fail;
> +			} else {
> +				/* This means our list of constructor is
> +				 * no the same as primary. Just remove
> +				 * that missing tailq and continue */
> +				TAILQ_REMOVE(&rte_tailq_elem_head, t, next);
> +			}
>   		}
>   	}
>   
I might be missing something here so bear with me.
The case you are trying to fix is, as an example, when your secondary 
app is using LPM but your primary is not.
So basically with this patch, you are removing the tailq for LPM on 
secondary and continuing as normal, is that the case?

I am not convinced about this approach.
I guess the assumption here is that all the TAILQ infrastructure works 
even when the tailq list itself is NULL?
I say assumption because I don't have an easy way to trigger this use 
case with default DPDK sample/test apps.

What about letting the secondary process create a tailq if it doesn't 
exists?
We would need to lock protect at least the register function to avoid 
race conditions when having multiple secondary processes.

David, what do you think?

Sergio

Re: [dpdk-dev] [PATCH 1/1] eal: Don't fail secondary if primary is missing tailqs

[Jean Tourrilhes]

On Tue, Oct 04, 2016 at 02:11:39PM +0100, Sergio Gonzalez Monroy wrote:
> Hi Jean,
> 
> As with your other patch, commit title needs fixing and also missing
> Signed-off-by line.

	I'll do that, no worries...

> I might be missing something here so bear with me.

	Yes, I know I was terse. Sorry.

> The case you are trying to fix is, as an example, when your secondary app is
> using LPM but your primary is not.
> So basically with this patch, you are removing the tailq for LPM on
> secondary and continuing as normal, is that the case?

	The secondary can't use tailq types that the primary does not
have, because they are shared across the shared memory.

	What happens is that the primary and secondary did not compile
in the same list of tailq. See previous e-mail :
		http://dpdk.org/ml/archives/dev/2016-September/047329.html
	The reason it's happening is that the secondary was not
compiled with the DPDK build system, but with the build system of the
application (in this case, Snort). Oubviously, porting the application
to the DPDK build system is not practical, so we need to live with
this case.
	The build system of the application does not have all the
subtelties of the DPDK build system, and ends up including *all* the
constructors, wether they are used or not in the code. Moreover, they
are included in a different order. Actually, by default the builds
include no constructors at all (which is a big fail), so the library
needs to be included with --whole-archive (see Snort DPDK
instructions).

> I am not convinced about this approach.

	I agree that the whole constructor approach is flaky and my
patch is only a band aid. Constructors should be entirely removed
IMHO, and a more deterministic init method should be used instead of
depending on linker magic.
	Note that the other constructors happen to work right in my
case, but that's probably pure luck. The list of mempool constructors
happen to be the same and in the same order (order matters for mempool
constructors). The app is not using spinlock, hash, crc and acl, so
I did not look if the lists did match.

> I guess the assumption here is that all the TAILQ infrastructure works even
> when the tailq list itself is NULL?

	If tailq are not used in the primary, I assume it would work.

> I say assumption because I don't have an easy way to trigger this use case
> with default DPDK sample/test apps.

	I know. I'll see what I can do to release the code.

> What about letting the secondary process create a tailq if it doesn't
> exists?

	Primary owns the shared memory, and I don't see how primary
could handle an unknown tailq. Secondary can't do much without
primary. So, I don't see how adding the missing tailqs helps.

> We would need to lock protect at least the register function to avoid race
> conditions when having multiple secondary processes.
> 
> David, what do you think?
> 
> Sergio

	Regards,

	Jean

Re: [dpdk-dev] [PATCH 1/1] eal: Don't fail secondary if primary is missing tailqs

[David Marchand]

Hello,

On Tue, Oct 4, 2016 at 6:59 PM, Jean Tourrilhes <jt@labs.hpe.com> wrote:
> On Tue, Oct 04, 2016 at 02:11:39PM +0100, Sergio Gonzalez Monroy wrote:
>> The case you are trying to fix is, as an example, when your secondary app is
>> using LPM but your primary is not.
>> So basically with this patch, you are removing the tailq for LPM on
>> secondary and continuing as normal, is that the case?
>
>         The secondary can't use tailq types that the primary does not
> have, because they are shared across the shared memory.

I am not a "multi process" user but afaik the primary process is
responsible for filling the shared memory.
The secondary processes look at it.
So having unaligned processes can't work.


>         What happens is that the primary and secondary did not compile
> in the same list of tailq. See previous e-mail :
>                 http://dpdk.org/ml/archives/dev/2016-September/047329.html
>         The reason it's happening is that the secondary was not
> compiled with the DPDK build system, but with the build system of the
> application (in this case, Snort). Oubviously, porting the application
> to the DPDK build system is not practical, so we need to live with
> this case.
>         The build system of the application does not have all the
> subtelties of the DPDK build system, and ends up including *all* the
> constructors, wether they are used or not in the code. Moreover, they
> are included in a different order. Actually, by default the builds
> include no constructors at all (which is a big fail), so the library
> needs to be included with --whole-archive (see Snort DPDK
> instructions).

I thought you had unaligned binaries.
You are compiling only one binary ?


>> I am not convinced about this approach.
>
>         I agree that the whole constructor approach is flaky and my
> patch is only a band aid. Constructors should be entirely removed
> IMHO, and a more deterministic init method should be used instead of
> depending on linker magic.
>         Note that the other constructors happen to work right in my
> case, but that's probably pure luck. The list of mempool constructors
> happen to be the same and in the same order (order matters for mempool
> constructors). The app is not using spinlock, hash, crc and acl, so
> I did not look if the lists did match.


I am not sure Sergio is talking about the constructor approach.

Anyway, the constructors invocation order should not matter.
Primary and secondary processes build their local tailq entries list
in constructors (so far, I can't see how this is wrong).
"Later", each process updates this list with the actual pointer to the
lists by looking at the shared memory in rte_eal_init (calling
rte_eal_tailqs_init).

What matters is that secondary tailqs are a subset of the primary tailqs.


I still have some trouble understanding what you are trying to do.
As Sergio asked, can you come up with a simplified example/use case ?

Thanks.


-- 
David Marchand

Re: [dpdk-dev] [PATCH 1/1] eal: Don't fail secondary if primary is missing tailqs

[Jean Tourrilhes]

On Wed, Oct 05, 2016 at 09:58:01AM +0200, David Marchand wrote:
> Hello,

	Hi there,

> I thought you had unaligned binaries.
> You are compiling only one binary ?

	Primary is compiled using the DPDK build process.
	Secondary is build using the Snort build process.
	Both are pointing to the exact same libdpdk.a.

> I am not sure Sergio is talking about the constructor approach.

	But, this is exactly the cause of the problem.

> Anyway, the constructors invocation order should not matter.

	For tailq, I agree. For mempool constructors, order do matter.

> Primary and secondary processes build their local tailq entries list
> in constructors (so far, I can't see how this is wrong).
> "Later", each process updates this list with the actual pointer to the
> lists by looking at the shared memory in rte_eal_init (calling
> rte_eal_tailqs_init).
> 
> What matters is that secondary tailqs are a subset of the primary tailqs.

	Which is not the case for me, I have secondary including all
tailqs, and primary only having a subset.
	Check here :
		http://dpdk.org/ml/archives/dev/2016-September/047329.html

> I still have some trouble understanding what you are trying to do.

	Having things work ;-)

> As Sergio asked, can you come up with a simplified example/use case ?

	Not trivial. I'll see what I can do.

> Thanks.
> 
> 
> -- 
> David Marchand

	Regards,

	Jean

Re: [dpdk-dev] [PATCH 1/1] eal: Don't fail secondary if primary is missing tailqs

[Thomas Monjalon]

2016-10-05 09:49, Jean Tourrilhes:
> On Wed, Oct 05, 2016 at 09:58:01AM +0200, David Marchand wrote:
> > I thought you had unaligned binaries.
> > You are compiling only one binary ?
> 
> 	Primary is compiled using the DPDK build process.
> 	Secondary is build using the Snort build process.
> 	Both are pointing to the exact same libdpdk.a.

Probably that you would have some aligned builds if Snort was using
a pkg-config approach to link DPDK.
I cannot commit but I would like to generate some pkg-config files
in the DPDK build system to ease linking from external applications.

> > I am not sure Sergio is talking about the constructor approach.
> 
> 	But, this is exactly the cause of the problem.
> 
> > Anyway, the constructors invocation order should not matter.
> 
> 	For tailq, I agree. For mempool constructors, order do matter.

I don't know why such a complex function (rte_mempool_register_ops) is
called inside a constructor. Maybe that's the main problem.

Re: [dpdk-dev] [PATCH 1/1] eal: Don't fail secondary if primary is missing tailqs

[Jean Tourrilhes]

On Wed, Oct 05, 2016 at 07:09:14PM +0200, Thomas Monjalon wrote:
> 
> Probably that you would have some aligned builds if Snort was using
> a pkg-config approach to link DPDK.

	I seriously doubt it, but maybe there is some deep linker
magic that would pick the appropriate set of constructor.

> > 	For tailq, I agree. For mempool constructors, order do matter.
> 
> I don't know why such a complex function (rte_mempool_register_ops) is
> called inside a constructor. Maybe that's the main problem.

	No. The problem is that the list of constructors linked by the
linker in each binary is different, whereas DPDK expect them to be the
same.
	Regards,

	Jean

[dpdk-dev] [PATCH v2] eal: don't fail secondary if primary is missing tailqs

[Jean Tourrilhes]

If the primary and secondary process were build using different build
systems, the list of constructors included by the linker in each
binary might be different. Tailqs are registered via constructors, so
the linker magic will directly impact which tailqs are registered with
the primary and the secondary.

DPDK currently assumes that the secondary has a subset of the tailqs
registered at the primary. In some build scenario, the secondary might
register a tailq that the primary did not register. In this case,
instead of exiting with a panic, just unregister the offending tailq
and allow the secondary to run.

Signed-off-by: Jean Tourrilhes <jt@labs.hpe.com>
---
 lib/librte_eal/common/eal_common_tailqs.c | 18 ++++++++++++++----
 1 file changed, 14 insertions(+), 4 deletions(-)

diff --git a/lib/librte_eal/common/eal_common_tailqs.c b/lib/librte_eal/common/eal_common_tailqs.c
index bb08ec8..cf5a771 100644
--- a/lib/librte_eal/common/eal_common_tailqs.c
+++ b/lib/librte_eal/common/eal_common_tailqs.c
@@ -143,6 +143,8 @@ rte_eal_tailq_update(struct rte_tailq_elem *t)
 		t->head = rte_eal_tailq_create(t->name);
 	} else {
 		t->head = rte_eal_tailq_lookup(t->name);
+		if (t->head != NULL)
+			rte_tailqs_count++;
 	}
 }
 
@@ -178,19 +180,27 @@ int
 rte_eal_tailqs_init(void)
 {
 	struct rte_tailq_elem *t;
+	void *tmp_te;
 
 	rte_tailqs_count = 0;
 
-	TAILQ_FOREACH(t, &rte_tailq_elem_head, next) {
+	TAILQ_FOREACH_SAFE(t, &rte_tailq_elem_head, next, tmp_te) {
 		/* second part of register job for "early" tailqs, see
 		 * rte_eal_tailq_register and EAL_REGISTER_TAILQ */
 		rte_eal_tailq_update(t);
 		if (t->head == NULL) {
 			RTE_LOG(ERR, EAL,
 				"Cannot initialize tailq: %s\n", t->name);
-			/* no need to TAILQ_REMOVE, we are going to panic in
-			 * rte_eal_init() */
-			goto fail;
+			if (rte_eal_process_type() == RTE_PROC_PRIMARY) {
+				/* no need to TAILQ_REMOVE, we are going
+				 * to panic in rte_eal_init() */
+				goto fail;
+			} else {
+				/* This means our list of constructor is
+				 * no the same as primary. Just remove
+				 * that missing tailq and continue */
+				TAILQ_REMOVE(&rte_tailq_elem_head, t, next);
+			}
 		}
 	}
 

Re: [dpdk-dev] [PATCH v2] eal: don't fail secondary if primary is missing tailqs

[Ferruh Yigit]

On 10/5/2016 6:47 PM, jt at labs.hpe.com (Jean Tourrilhes) wrote:
> If the primary and secondary process were build using different build
> systems, the list of constructors included by the linker in each
> binary might be different. Tailqs are registered via constructors, so
> the linker magic will directly impact which tailqs are registered with
> the primary and the secondary.
> 
> DPDK currently assumes that the secondary has a subset of the tailqs
> registered at the primary. In some build scenario, the secondary might
> register a tailq that the primary did not register. In this case,
> instead of exiting with a panic, just unregister the offending tailq
> and allow the secondary to run.
> 
> Signed-off-by: Jean Tourrilhes <jt at labs.hpe.com>

A lot changed in multiprocess support in last two years, updating status of this
patch as 'Rejected', if the issue is still valid can you please either send a
new version or report the issue in bugzilla?

Thanks,
ferruh

[dpdk-dev] [PATCH 1/1] eal: Don't fail secondary if primary is missing tailqs

[Burdick, Cliff]

This patch was submitted by Jean Tourrilhes over two years ago, but didn't receive any responses. I hit the same issue recently when trying to use cgo (Golang) as a primary process linked to libdpdk.a against a C++ application linked against the same library. The history of the patch is here:

https://dev.dpdk.narkive.com/ZM3a7QD1/dpdk-dev-bug-static-constructors-considered-evil

and the original patch is here:

http://mails.dpdk.org/archives/dev/2016-September/047332.html

Can someone please give this another look? I don't see any other way to do a workaround short of applying this patch.


Signed-off-by: Cliff Burdick cliff.burdick@viasat.com<mailto:cliff.burdick@viasat.com>

---
lib/librte_eal/common/eal_common_tailqs.c | 15 ++++++++++++---
1 file changed, 12 insertions(+), 3 deletions(-)

diff --git a/lib/librte_eal/common/eal_common_tailqs.c b/lib/librte_eal/common/eal_common_tailqs.c
index bb08ec8..6960d06 100644
--- a/lib/librte_eal/common/eal_common_tailqs.c
+++ b/lib/librte_eal/common/eal_common_tailqs.c
@@ -143,6 +143,8 @@ rte_eal_tailq_update(struct rte_tailq_elem *t)
              t->head = rte_eal_tailq_create(t->name);
       } else {
              t->head = rte_eal_tailq_lookup(t->name);
+              if (t->head != NULL)
+                      rte_tailqs_count++;
       }
}
@@ -188,9 +190,16 @@ rte_eal_tailqs_init(void)
              if (t->head == NULL) {
                      RTE_LOG(ERR, EAL,
                              "Cannot initialize tailq: %s\n", t->name);
-                      /* no need to TAILQ_REMOVE, we are going to panic in
-                      * rte_eal_init() */
-                      goto fail;
+                      if (rte_eal_process_type() == RTE_PROC_PRIMARY) {
+                              /* no need to TAILQ_REMOVE, we are going
+                              * to panic in rte_eal_init() */
+                              goto fail;
+                      } else {
+                              /* This means our list of constructor is
+                              * no the same as primary. Just remove
+                              * that missing tailq and continue */
+                              TAILQ_REMOVE(&rte_tailq_elem_head, t, next);
+                      }
              }
       }

Re: [dpdk-dev] [PATCH 1/1] eal: Don't fail secondary if primary is missing tailqs

[Thomas Monjalon]

13/11/2018 00:33, Burdick, Cliff:
> This patch was submitted by Jean Tourrilhes over two years ago, but didn't receive any responses. I hit the same issue recently when trying to use cgo (Golang) as a primary process linked to libdpdk.a against a C++ application linked against the same library.

The question is to know why you don't have the same constructors in primary and seconday?

Re: [dpdk-dev] [PATCH 1/1] eal: Don't fail secondary if primary is missing tailqs

[Burakov, Anatoly]

On 13-Nov-18 9:21 AM, Thomas Monjalon wrote:
> 13/11/2018 00:33, Burdick, Cliff:
>> This patch was submitted by Jean Tourrilhes over two years ago, but didn't receive any responses. I hit the same issue recently when trying to use cgo (Golang) as a primary process linked to libdpdk.a against a C++ application linked against the same library.
> 
> The question is to know why you don't have the same constructors in primary and seconday?
> 

I've hit similar things in the past. I believe it was caused by our 
build system stripping out unused libraries (such as rte_hash) from the 
binary and thus not calling the constructor in the primary, but doing so 
in the secondary (or something to that effect). In any case, this is 
caused by linking different number of libraries to primary and 
secondary, and should probably be fixed in the build system, not in the 
tailqs code (unless we specifically support having different linked 
libraries to primary and secondary?).

-- 
Thanks,
Anatoly

Re: [dpdk-dev] [PATCH 1/1] eal: Don't fail secondary if primary is missing tailqs

[Burdick, Cliff]

-----Original Message-----
From: Burakov, Anatoly [mailto:anatoly.burakov@intel.com] 
Sent: Tuesday, November 13, 2018 1:39 AM
To: Thomas Monjalon; Burdick, Cliff
Cc: dev@dpdk.org
Subject: Re: [dpdk-dev] [PATCH 1/1] eal: Don't fail secondary if primary is missing tailqs

On 13-Nov-18 9:21 AM, Thomas Monjalon wrote:
> 13/11/2018 00:33, Burdick, Cliff:
>> This patch was submitted by Jean Tourrilhes over two years ago, but didn't receive any responses. I hit the same issue recently when trying to use cgo (Golang) as a primary process linked to libdpdk.a against a C++ application linked against the same library.
> 
> The question is to know why you don't have the same constructors in primary and seconday?
> 

> I've hit similar things in the past. I believe it was caused by our build system stripping out unused libraries (such as rte_hash) from the binary and thus not calling the constructor in the primary, but doing so in the secondary (or something to that effect).
> In any case, this is caused by linking different number of libraries to primary and secondary, and should probably be fixed in the build system, not in the tailqs code (unless we specifically support having different linked libraries to primary and secondary?).

Right, I think the original author of the patch stated the reasons in the link I provided. The build system seems like the most appropriate place to fix it, but the patch got me going quickly. I think the question is whether you want DPDK to support these other ways of linking. I'm certainly not the first to use cgo, since there's a virtual switch project doing the same:

https://github.com/lagopus/vsw

They don't use primary/secondary processes, though, so the issue is never hit. I'm in a situation where using cgo seemed like the easiest path to accomplish what I'm doing since I needed specialized libraries for it that were not available in C/C++. At some point I bet someone would use Cython to start linking against DPDK as well, and we'd likely run into the same issue.

Re: [dpdk-dev] [PATCH 1/1] eal: Don't fail secondary if primary is missing tailqs

[Thomas Monjalon]

13/11/2018 16:45, Burdick, Cliff:
> From: Burakov, Anatoly [mailto:anatoly.burakov@intel.com] 
> > On 13-Nov-18 9:21 AM, Thomas Monjalon wrote:
> > > 13/11/2018 00:33, Burdick, Cliff:
> > >> This patch was submitted by Jean Tourrilhes over two years ago, but
> > >> didn't receive any responses. I hit the same issue recently when
> > >> trying to use cgo (Golang) as a primary process linked to libdpdk.a
> > >> against a C++ application linked against the same library.> > > 
> > > 
> > > The question is to know why you don't have the same constructors in
> > > primary and seconday?
> > 
> > I've hit similar things in the past. I believe it was caused by our build system stripping out unused libraries (such as rte_hash) from the binary and thus not calling the constructor in the primary, but doing so in the secondary (or something to that effect).
> > In any case, this is caused by linking different number of libraries to primary and secondary, and should probably be fixed in the build system, not in the tailqs code (unless we specifically support having different linked libraries to primary and secondary?).
> 
> Right, I think the original author of the patch stated the reasons in the link I provided. The build system seems like the most appropriate place to fix it, but the patch got me going quickly. I think the question is whether you want DPDK to support these other ways of linking. I'm certainly not the first to use cgo, since there's a virtual switch project doing the same:
> 
> https://github.com/lagopus/vsw
> 
> They don't use primary/secondary processes, though, so the issue is never hit. I'm in a situation where using cgo seemed like the easiest path to accomplish what I'm doing since I needed specialized libraries for it that were not available in C/C++. At some point I bet someone would use Cython to start linking against DPDK as well, and we'd likely run into the same issue.

For sure, we want to support using DPDK with cgo or cython.
But it is not clear what is the relation with not having the same compilation
for primary and secondary. Please could you elaborate?

Re: [dpdk-dev] [PATCH 1/1] eal: Don't fail secondary if primary is missing tailqs

[Burdick, Cliff]

-----Original Message-----
From: Thomas Monjalon [mailto:thomas@monjalon.net] 
Sent: Tuesday, November 13, 2018 8:07 AM
To: Burdick, Cliff
Cc: Burakov, Anatoly; dev@dpdk.org
Subject: Re: [dpdk-dev] [PATCH 1/1] eal: Don't fail secondary if primary is missing tailqs

13/11/2018 16:45, Burdick, Cliff:
> From: Burakov, Anatoly [mailto:anatoly.burakov@intel.com]
> > On 13-Nov-18 9:21 AM, Thomas Monjalon wrote:
> > > 13/11/2018 00:33, Burdick, Cliff:
> > >> This patch was submitted by Jean Tourrilhes over two years ago, 
> > >> but didn't receive any responses. I hit the same issue recently 
> > >> when trying to use cgo (Golang) as a primary process linked to 
> > >> libdpdk.a against a C++ application linked against the same 
> > >> library.> > >
> > > 
> > > The question is to know why you don't have the same constructors 
> > > in primary and seconday?
> > 
> > I've hit similar things in the past. I believe it was caused by our build system stripping out unused libraries (such as rte_hash) from the binary and thus not calling the constructor in the primary, but doing so in the secondary (or something to that effect).
> > In any case, this is caused by linking different number of libraries to primary and secondary, and should probably be fixed in the build system, not in the tailqs code (unless we specifically support having different linked libraries to primary and secondary?).
> 
> Right, I think the original author of the patch stated the reasons in the link I provided. The build system seems like the most appropriate place to fix it, but the patch got me going quickly. I think the question is whether you want DPDK to support these other ways of linking. I'm certainly not the first to use cgo, since there's a virtual switch project doing the same:
> 
> https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_lagopu
> s_vsw&d=DwICAg&c=jcv3orpCsv7C4ly8-ubDoUfrxF5xIGWmptxGWP5vi5w&r=m1RLQOG
> Okz9MauvVLZmiGtyWc5mA7DejbPFNE1IDj-4&m=hQqVCNwW7eoEzB_hLFK97i8idS8FIqX
> oPeclwsIZq7Y&s=BMoBlwkqljwWIBY3SE3pPMCfVnOUlDuZLrno4-SojKM&e=
> 
> They don't use primary/secondary processes, though, so the issue is never hit. I'm in a situation where using cgo seemed like the easiest path to accomplish what I'm doing since I needed specialized libraries for it that were not available in C/C++. At some point I bet someone would use Cython to start linking against DPDK as well, and we'd likely run into the same issue.

>For sure, we want to support using DPDK with cgo or cython.
>But it is not clear what is the relation with not having the same compilation for primary and secondary. Please could you elaborate?

Hi Thomas, I think Jean explained it well here: https://dev.dpdk.narkive.com/ZM3a7QD1/dpdk-dev-bug-static-constructors-considered-evil

"The build system of the application does not have all the
subtelties of the DPDK build system, and ends up including *all* the
constructors, wether they are used or not in the code. Moreover, they
are included in a different order. Actually, by default the builds
include no constructors at all (which is a big fail), so the library
needs to be included with --whole-archive (see Snort DPDK
instructions)."

I will get to the bottom of my exact case to understand what's happening, but my primary application is a cgo application that I'm linking to by using almost exactly the same flags that are used in the DPDK build system to build examples. The DPDK libraries I'm linking against is a single location for both primary and secondary; in other words, I don't build DPDK twice. 

You had alluded to a pkg-config for DPDK in the 2015 thread, which cgo can use, but I don't know if that ever was implemented. Cgo can use pkg-config if it's available, otherwise the only tools are specifying LDFLAGS and CFLAGS into their build system.

Re: [dpdk-dev] [PATCH 1/1] eal: Don't fail secondary if primary is missing tailqs

[Thomas Monjalon]

13/11/2018 17:38, Burdick, Cliff:
> 
> -----Original Message-----
> From: Thomas Monjalon [mailto:thomas@monjalon.net] 
> Sent: Tuesday, November 13, 2018 8:07 AM
> To: Burdick, Cliff
> Cc: Burakov, Anatoly; dev@dpdk.org
> Subject: Re: [dpdk-dev] [PATCH 1/1] eal: Don't fail secondary if primary is missing tailqs
> 
> 13/11/2018 16:45, Burdick, Cliff:
> > From: Burakov, Anatoly [mailto:anatoly.burakov@intel.com]
> > > On 13-Nov-18 9:21 AM, Thomas Monjalon wrote:
> > > > 13/11/2018 00:33, Burdick, Cliff:
> > > >> This patch was submitted by Jean Tourrilhes over two years ago, 
> > > >> but didn't receive any responses. I hit the same issue recently 
> > > >> when trying to use cgo (Golang) as a primary process linked to 
> > > >> libdpdk.a against a C++ application linked against the same 
> > > >> library.> > >
> > > > 
> > > > The question is to know why you don't have the same constructors 
> > > > in primary and seconday?
> > > 
> > > I've hit similar things in the past. I believe it was caused by our build system stripping out unused libraries (such as rte_hash) from the binary and thus not calling the constructor in the primary, but doing so in the secondary (or something to that effect).
> > > In any case, this is caused by linking different number of libraries to primary and secondary, and should probably be fixed in the build system, not in the tailqs code (unless we specifically support having different linked libraries to primary and secondary?).
> > 
> > Right, I think the original author of the patch stated the reasons in the link I provided. The build system seems like the most appropriate place to fix it, but the patch got me going quickly. I think the question is whether you want DPDK to support these other ways of linking. I'm certainly not the first to use cgo, since there's a virtual switch project doing the same:
> > 
> > https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_lagopu
> > s_vsw&d=DwICAg&c=jcv3orpCsv7C4ly8-ubDoUfrxF5xIGWmptxGWP5vi5w&r=m1RLQOG
> > Okz9MauvVLZmiGtyWc5mA7DejbPFNE1IDj-4&m=hQqVCNwW7eoEzB_hLFK97i8idS8FIqX
> > oPeclwsIZq7Y&s=BMoBlwkqljwWIBY3SE3pPMCfVnOUlDuZLrno4-SojKM&e=
> > 
> > They don't use primary/secondary processes, though, so the issue is never hit. I'm in a situation where using cgo seemed like the easiest path to accomplish what I'm doing since I needed specialized libraries for it that were not available in C/C++. At some point I bet someone would use Cython to start linking against DPDK as well, and we'd likely run into the same issue.
> 
> >For sure, we want to support using DPDK with cgo or cython.
> >But it is not clear what is the relation with not having the same compilation for primary and secondary. Please could you elaborate?
> 
> Hi Thomas, I think Jean explained it well here: https://dev.dpdk.narkive.com/ZM3a7QD1/dpdk-dev-bug-static-constructors-considered-evil
> 
> "The build system of the application does not have all the
> subtelties of the DPDK build system, and ends up including *all* the
> constructors, wether they are used or not in the code. Moreover, they
> are included in a different order. Actually, by default the builds
> include no constructors at all (which is a big fail), so the library
> needs to be included with --whole-archive (see Snort DPDK
> instructions)."
> 
> I will get to the bottom of my exact case to understand what's happening, but my primary application is a cgo application that I'm linking to by using almost exactly the same flags that are used in the DPDK build system to build examples. The DPDK libraries I'm linking against is a single location for both primary and secondary; in other words, I don't build DPDK twice. 

OK I understand, thanks.

> You had alluded to a pkg-config for DPDK in the 2015 thread, which cgo can use, but I don't know if that ever was implemented. Cgo can use pkg-config if it's available, otherwise the only tools are specifying LDFLAGS and CFLAGS into their build system.

Yes, the right answer is still pkg-config :)
The good news is that it is now implemented thanks to the meson build system:
	http://git.dpdk.org/dpdk/tree/doc/build-sdk-meson.txt#n182

Re: [dpdk-dev] [PATCH 1/1] eal: Don't fail secondary if primary is missing tailqs

[Burdick, Cliff]

-----Original Message-----
From: Thomas Monjalon [mailto:thomas@monjalon.net] 
Sent: Tuesday, November 13, 2018 8:44 AM
To: Burdick, Cliff
Cc: Burakov, Anatoly; dev@dpdk.org; bruce.richardson@intel.com
Subject: Re: [dpdk-dev] [PATCH 1/1] eal: Don't fail secondary if primary is missing tailqs

13/11/2018 17:38, Burdick, Cliff:
> 
> -----Original Message-----
> From: Thomas Monjalon [mailto:thomas@monjalon.net]
> Sent: Tuesday, November 13, 2018 8:07 AM
> To: Burdick, Cliff
> Cc: Burakov, Anatoly; dev@dpdk.org
> Subject: Re: [dpdk-dev] [PATCH 1/1] eal: Don't fail secondary if 
> primary is missing tailqs
> 
> 13/11/2018 16:45, Burdick, Cliff:
> > From: Burakov, Anatoly [mailto:anatoly.burakov@intel.com]
> > > On 13-Nov-18 9:21 AM, Thomas Monjalon wrote:
> > > > 13/11/2018 00:33, Burdick, Cliff:
> > > >> This patch was submitted by Jean Tourrilhes over two years ago, 
> > > >> but didn't receive any responses. I hit the same issue recently 
> > > >> when trying to use cgo (Golang) as a primary process linked to 
> > > >> libdpdk.a against a C++ application linked against the same 
> > > >> library.> > >
> > > > 
> > > > The question is to know why you don't have the same constructors 
> > > > in primary and seconday?
> > > 
> > > I've hit similar things in the past. I believe it was caused by our build system stripping out unused libraries (such as rte_hash) from the binary and thus not calling the constructor in the primary, but doing so in the secondary (or something to that effect).
> > > In any case, this is caused by linking different number of libraries to primary and secondary, and should probably be fixed in the build system, not in the tailqs code (unless we specifically support having different linked libraries to primary and secondary?).
> > 
> > Right, I think the original author of the patch stated the reasons in the link I provided. The build system seems like the most appropriate place to fix it, but the patch got me going quickly. I think the question is whether you want DPDK to support these other ways of linking. I'm certainly not the first to use cgo, since there's a virtual switch project doing the same:
> > 
> > https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_lago
> > pu 
> > s_vsw&d=DwICAg&c=jcv3orpCsv7C4ly8-ubDoUfrxF5xIGWmptxGWP5vi5w&r=m1RLQ
> > OG 
> > Okz9MauvVLZmiGtyWc5mA7DejbPFNE1IDj-4&m=hQqVCNwW7eoEzB_hLFK97i8idS8FI
> > qX oPeclwsIZq7Y&s=BMoBlwkqljwWIBY3SE3pPMCfVnOUlDuZLrno4-SojKM&e=
> > 
> > They don't use primary/secondary processes, though, so the issue is never hit. I'm in a situation where using cgo seemed like the easiest path to accomplish what I'm doing since I needed specialized libraries for it that were not available in C/C++. At some point I bet someone would use Cython to start linking against DPDK as well, and we'd likely run into the same issue.
> 
> >For sure, we want to support using DPDK with cgo or cython.
> >But it is not clear what is the relation with not having the same compilation for primary and secondary. Please could you elaborate?
> 
> Hi Thomas, I think Jean explained it well here: 
> https://urldefense.proofpoint.com/v2/url?u=https-3A__dev.dpdk.narkive.
> com_ZM3a7QD1_dpdk-2Ddev-2Dbug-2Dstatic-2Dconstructors-2Dconsidered-2De
> vil&d=DwICAg&c=jcv3orpCsv7C4ly8-ubDoUfrxF5xIGWmptxGWP5vi5w&r=m1RLQOGOk
> z9MauvVLZmiGtyWc5mA7DejbPFNE1IDj-4&m=C69wDgrjDX8_oXp1M_3bnmWOOZdGqwBBG
> 9vzkyGDWGQ&s=YYn2N7WrzJpH1ptNrLZad0nPAQdrUyqBckk2uFuWYPQ&e=
> 
> "The build system of the application does not have all the subtelties 
> of the DPDK build system, and ends up including *all* the 
> constructors, wether they are used or not in the code. Moreover, they 
> are included in a different order. Actually, by default the builds 
> include no constructors at all (which is a big fail), so the library 
> needs to be included with --whole-archive (see Snort DPDK 
> instructions)."
> 
> I will get to the bottom of my exact case to understand what's happening, but my primary application is a cgo application that I'm linking to by using almost exactly the same flags that are used in the DPDK build system to build examples. The DPDK libraries I'm linking against is a single location for both primary and secondary; in other words, I don't build DPDK twice. 

> OK I understand, thanks.

> You had alluded to a pkg-config for DPDK in the 2015 thread, which cgo can use, but I don't know if that ever was implemented. Cgo can use pkg-config if it's available, otherwise the only tools are specifying LDFLAGS and CFLAGS into their build system.

>Yes, the right answer is still pkg-config :) The good news is that it is now implemented thanks to the meson build system:
>	https://urldefense.proofpoint.com/v2/url?u=http-3A__git.dpdk.org_dpdk_tree_doc_build-2Dsdk-2Dmeson.txt-23n182&d=DwICAg&c=jcv3orpCsv7C4ly8-ubDoUfrxF5xIGWmptxGWP5vi5w&r=m1RLQOGOkz9MauvVLZmiGtyWc5mA7DejbPFNE1IDj->4&m=C69wDgrjDX8_oXp1M_3bnmWOOZdGqwBBG9vzkyGDWGQ&s=oC86KD_RJ1T6rfzi3x5zFT1Ri13ELpKmsyFqpgDbgFg&e=

Hi Thomas, are there instructions on how to use pkg-config to build the mlx4/5 PMD? I noticed a patch was submitted in September to add support for it, but that link you provided on using meson doesn't say how to build specific drivers. It appears to be disabled by default.

Re: [dpdk-dev] [PATCH 1/1] eal: Don't fail secondary if primary is missing tailqs

[Thomas Monjalon]

13/11/2018 23:08, Burdick, Cliff:
> From: Thomas Monjalon [mailto:thomas@monjalon.net] 
> > 13/11/2018 17:38, Burdick, Cliff:
> > > From: Thomas Monjalon [mailto:thomas@monjalon.net]
> > > 13/11/2018 16:45, Burdick, Cliff:
> > > > From: Burakov, Anatoly [mailto:anatoly.burakov@intel.com]
> > > > > On 13-Nov-18 9:21 AM, Thomas Monjalon wrote:
> > > > > > 13/11/2018 00:33, Burdick, Cliff:
> > > > > >> This patch was submitted by Jean Tourrilhes over two years ago,
> > > > > >> but didn't receive any responses. I hit the same issue recently
> > > > > >> when trying to use cgo (Golang) as a primary process linked to
> > > > > >> libdpdk.a against a C++ application linked against the same
> > > > > >> library.> > >
> > > > > > 
> > > > > > The question is to know why you don't have the same constructors
> > > > > > in primary and seconday?
> > > > > 
> > > > > I've hit similar things in the past. I believe it was caused by our
> > > > > build system stripping out unused libraries (such as rte_hash) from
> > > > > the binary and thus not calling the constructor in the primary, but
> > > > > doing so in the secondary (or something to that effect). In any
> > > > > case, this is caused by linking different number of libraries to
> > > > > primary and secondary, and should probably be fixed in the build
> > > > > system, not in the tailqs code (unless we specifically support
> > > > > having different linked libraries to primary and secondary?).> > > > 
> > > > Right, I think the original author of the patch stated the reasons in
> > > > the link I provided. The build system seems like the most appropriate
> > > > place to fix it, but the patch got me going quickly. I think the
> > > > question is whether you want DPDK to support these other ways of
> > > > linking. I'm certainly not the first to use cgo, since there's a
> > > > virtual switch project doing the same:
> > > > 
> > > > https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_lago
> > > > pu
> > > > s_vsw&d=DwICAg&c=jcv3orpCsv7C4ly8-ubDoUfrxF5xIGWmptxGWP5vi5w&r=m1RLQ
> > > > OG
> > > > Okz9MauvVLZmiGtyWc5mA7DejbPFNE1IDj-4&m=hQqVCNwW7eoEzB_hLFK97i8idS8FI
> > > > qX oPeclwsIZq7Y&s=BMoBlwkqljwWIBY3SE3pPMCfVnOUlDuZLrno4-SojKM&e=
> > > > 
> > > > They don't use primary/secondary processes, though, so the issue is
> > > > never hit. I'm in a situation where using cgo seemed like the easiest
> > > > path to accomplish what I'm doing since I needed specialized
> > > > libraries for it that were not available in C/C++. At some point I
> > > > bet someone would use Cython to start linking against DPDK as well,
> > > > and we'd likely run into the same issue.> > > >
> > > >For sure, we want to support using DPDK with cgo or cython.
> > > >But it is not clear what is the relation with not having the same
> > > >compilation for primary and secondary. Please could you elaborate?> > > 
> > > Hi Thomas, I think Jean explained it well here:
> > > https://urldefense.proofpoint.com/v2/url?u=https-3A__dev.dpdk.narkive.
> > > com_ZM3a7QD1_dpdk-2Ddev-2Dbug-2Dstatic-2Dconstructors-2Dconsidered-2De
> > > vil&d=DwICAg&c=jcv3orpCsv7C4ly8-ubDoUfrxF5xIGWmptxGWP5vi5w&r=m1RLQOGOk
> > > z9MauvVLZmiGtyWc5mA7DejbPFNE1IDj-4&m=C69wDgrjDX8_oXp1M_3bnmWOOZdGqwBBG
> > > 9vzkyGDWGQ&s=YYn2N7WrzJpH1ptNrLZad0nPAQdrUyqBckk2uFuWYPQ&e=
> > > 
> > > "The build system of the application does not have all the subtelties
> > > of the DPDK build system, and ends up including *all* the
> > > constructors, wether they are used or not in the code. Moreover, they
> > > are included in a different order. Actually, by default the builds
> > > include no constructors at all (which is a big fail), so the library
> > > needs to be included with --whole-archive (see Snort DPDK
> > > instructions)."
> > > 
> > > I will get to the bottom of my exact case to understand what's
> > > happening, but my primary application is a cgo application that I'm
> > > linking to by using almost exactly the same flags that are used in the
> > > DPDK build system to build examples. The DPDK libraries I'm linking
> > > against is a single location for both primary and secondary; in other
> > > words, I don't build DPDK twice.
> > > 
> > > OK I understand, thanks.
> > > 
> > > You had alluded to a pkg-config for DPDK in the 2015 thread, which cgo
> > > can use, but I don't know if that ever was implemented. Cgo can use
> > > pkg-config if it's available, otherwise the only tools are specifying
> > > LDFLAGS and CFLAGS into their build system.
> >Yes, the right answer is still pkg-config :) The good news is that it is now implemented thanks to the meson build system:
> >	https://urldefense.proofpoint.com/v2/url?u=http-3A__git.dpdk.org_dpdk_tree_doc_build-2Dsdk-2Dmeson.txt-23n182&d=DwICAg&c=jcv3orpCsv7C4ly8-ubDoUfrxF5xIGWmptxGWP5vi5w&r=m1RLQOGOkz9MauvVLZmiGtyWc5mA7DejbPFNE1IDj->4&m=C69wDgrjDX8_oXp1M_3bnmWOOZdGqwBBG9vzkyGDWGQ&s=oC86KD_RJ1T6rfzi3x5zFT1Ri13ELpKmsyFqpgDbgFg&e=
> 
> Hi Thomas, are there instructions on how to use pkg-config to build the mlx4/5 PMD? I noticed a patch was submitted in September to add support for it, but that link you provided on using meson doesn't say how to build specific drivers. It appears to be disabled by default.

If the dependency is found, meson will enable the PMD when building DPDK.

Re: [dpdk-dev] [PATCH 1/1] eal: Don't fail secondary if primary is missing tailqs

[Burdick, Cliff]

________________________________________
From: Thomas Monjalon [thomas@monjalon.net]
Sent: Tuesday, November 13, 2018 2:18 PM
To: Burdick, Cliff
Cc: Burakov, Anatoly; dev@dpdk.org; bruce.richardson@intel.com
Subject: Re: [dpdk-dev] [PATCH 1/1] eal: Don't fail secondary if primary is missing tailqs

13/11/2018 23:08, Burdick, Cliff:
> From: Thomas Monjalon [mailto:thomas@monjalon.net]
> > 13/11/2018 17:38, Burdick, Cliff:
> > > From: Thomas Monjalon [mailto:thomas@monjalon.net]
> > > 13/11/2018 16:45, Burdick, Cliff:
> > > > From: Burakov, Anatoly [mailto:anatoly.burakov@intel.com]
> > > > > On 13-Nov-18 9:21 AM, Thomas Monjalon wrote:
> > > > > > 13/11/2018 00:33, Burdick, Cliff:
> > > > > >> This patch was submitted by Jean Tourrilhes over two years ago,
> > > > > >> but didn't receive any responses. I hit the same issue recently
> > > > > >> when trying to use cgo (Golang) as a primary process linked to
> > > > > >> libdpdk.a against a C++ application linked against the same
> > > > > >> library.> > >
> > > > > >
> > > > > > The question is to know why you don't have the same constructors
> > > > > > in primary and seconday?
> > > > >
> > > > > I've hit similar things in the past. I believe it was caused by our
> > > > > build system stripping out unused libraries (such as rte_hash) from
> > > > > the binary and thus not calling the constructor in the primary, but
> > > > > doing so in the secondary (or something to that effect). In any
> > > > > case, this is caused by linking different number of libraries to
> > > > > primary and secondary, and should probably be fixed in the build
> > > > > system, not in the tailqs code (unless we specifically support
> > > > > having different linked libraries to primary and secondary?).> > > >
> > > > Right, I think the original author of the patch stated the reasons in
> > > > the link I provided. The build system seems like the most appropriate
> > > > place to fix it, but the patch got me going quickly. I think the
> > > > question is whether you want DPDK to support these other ways of
> > > > linking. I'm certainly not the first to use cgo, since there's a
> > > > virtual switch project doing the same:
> > > >
> > > > https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_lago
> > > > pu
> > > > s_vsw&d=DwICAg&c=jcv3orpCsv7C4ly8-ubDoUfrxF5xIGWmptxGWP5vi5w&r=m1RLQ
> > > > OG
> > > > Okz9MauvVLZmiGtyWc5mA7DejbPFNE1IDj-4&m=hQqVCNwW7eoEzB_hLFK97i8idS8FI
> > > > qX oPeclwsIZq7Y&s=BMoBlwkqljwWIBY3SE3pPMCfVnOUlDuZLrno4-SojKM&e=
> > > >
> > > > They don't use primary/secondary processes, though, so the issue is
> > > > never hit. I'm in a situation where using cgo seemed like the easiest
> > > > path to accomplish what I'm doing since I needed specialized
> > > > libraries for it that were not available in C/C++. At some point I
> > > > bet someone would use Cython to start linking against DPDK as well,
> > > > and we'd likely run into the same issue.> > > >
> > > >For sure, we want to support using DPDK with cgo or cython.
> > > >But it is not clear what is the relation with not having the same
> > > >compilation for primary and secondary. Please could you elaborate?> > >
> > > Hi Thomas, I think Jean explained it well here:
> > > https://urldefense.proofpoint.com/v2/url?u=https-3A__dev.dpdk.narkive.
> > > com_ZM3a7QD1_dpdk-2Ddev-2Dbug-2Dstatic-2Dconstructors-2Dconsidered-2De
> > > vil&d=DwICAg&c=jcv3orpCsv7C4ly8-ubDoUfrxF5xIGWmptxGWP5vi5w&r=m1RLQOGOk
> > > z9MauvVLZmiGtyWc5mA7DejbPFNE1IDj-4&m=C69wDgrjDX8_oXp1M_3bnmWOOZdGqwBBG
> > > 9vzkyGDWGQ&s=YYn2N7WrzJpH1ptNrLZad0nPAQdrUyqBckk2uFuWYPQ&e=
> > >
> > > "The build system of the application does not have all the subtelties
> > > of the DPDK build system, and ends up including *all* the
> > > constructors, wether they are used or not in the code. Moreover, they
> > > are included in a different order. Actually, by default the builds
> > > include no constructors at all (which is a big fail), so the library
> > > needs to be included with --whole-archive (see Snort DPDK
> > > instructions)."
> > >
> > > I will get to the bottom of my exact case to understand what's
> > > happening, but my primary application is a cgo application that I'm
> > > linking to by using almost exactly the same flags that are used in the
> > > DPDK build system to build examples. The DPDK libraries I'm linking
> > > against is a single location for both primary and secondary; in other
> > > words, I don't build DPDK twice.
> > >
> > > OK I understand, thanks.
> > >
> > > You had alluded to a pkg-config for DPDK in the 2015 thread, which cgo
> > > can use, but I don't know if that ever was implemented. Cgo can use
> > > pkg-config if it's available, otherwise the only tools are specifying
> > > LDFLAGS and CFLAGS into their build system.
> >Yes, the right answer is still pkg-config :) The good news is that it is now implemented thanks to the meson build system:
> >     https://urldefense.proofpoint.com/v2/url?u=http-3A__git.dpdk.org_dpdk_tree_doc_build-2Dsdk-2Dmeson.txt-23n182&d=DwICAg&c=jcv3orpCsv7C4ly8-ubDoUfrxF5xIGWmptxGWP5vi5w&r=m1RLQOGOkz9MauvVLZmiGtyWc5mA7DejbPFNE1IDj->4&m=C69wDgrjDX8_oXp1M_3bnmWOOZdGqwBBG9vzkyGDWGQ&s=oC86KD_RJ1T6rfzi3x5zFT1Ri13ELpKmsyFqpgDbgFg&e=
>
> Hi Thomas, are there instructions on how to use pkg-config to build the mlx4/5 PMD? I noticed a patch was submitted in September to add support for it, but that link you provided on using meson doesn't say how to build specific drivers. It appears to be disabled by default.

> If the dependency is found, meson will enable the PMD when building DPDK.

Do you know where exactly that is? I've been using mlx5 for a while on this system, and I can see that 18.11-rc2 meson build+ninja built the pmd, but it's not on the --libs listing for pkg-config. Does it tell me what I was missing?

Re: [dpdk-dev] [PATCH 1/1] eal: Don't fail secondary if primary is missing tailqs

[Bruce Richardson]

On Tue, Nov 13, 2018 at 11:42:51PM +0000, Burdick, Cliff wrote:
> 
> ________________________________________
> From: Thomas Monjalon [thomas@monjalon.net]
> Sent: Tuesday, November 13, 2018 2:18 PM
> To: Burdick, Cliff
> Cc: Burakov, Anatoly; dev@dpdk.org; bruce.richardson@intel.com
> Subject: Re: [dpdk-dev] [PATCH 1/1] eal: Don't fail secondary if primary is missing tailqs
> 
> 13/11/2018 23:08, Burdick, Cliff:
> > From: Thomas Monjalon [mailto:thomas@monjalon.net]
> > > 13/11/2018 17:38, Burdick, Cliff:
> > > > From: Thomas Monjalon [mailto:thomas@monjalon.net]
> > > > 13/11/2018 16:45, Burdick, Cliff:
> > > > > From: Burakov, Anatoly [mailto:anatoly.burakov@intel.com]
> > > > > > On 13-Nov-18 9:21 AM, Thomas Monjalon wrote:
> > > > > > > 13/11/2018 00:33, Burdick, Cliff:
> > > > > > >> This patch was submitted by Jean Tourrilhes over two years ago,
> > > > > > >> but didn't receive any responses. I hit the same issue recently
> > > > > > >> when trying to use cgo (Golang) as a primary process linked to
> > > > > > >> libdpdk.a against a C++ application linked against the same
> > > > > > >> library.> > >
> > > > > > >
> > > > > > > The question is to know why you don't have the same constructors
> > > > > > > in primary and seconday?
> > > > > >
> > > > > > I've hit similar things in the past. I believe it was caused by our
> > > > > > build system stripping out unused libraries (such as rte_hash) from
> > > > > > the binary and thus not calling the constructor in the primary, but
> > > > > > doing so in the secondary (or something to that effect). In any
> > > > > > case, this is caused by linking different number of libraries to
> > > > > > primary and secondary, and should probably be fixed in the build
> > > > > > system, not in the tailqs code (unless we specifically support
> > > > > > having different linked libraries to primary and secondary?).> > > >
> > > > > Right, I think the original author of the patch stated the reasons in
> > > > > the link I provided. The build system seems like the most appropriate
> > > > > place to fix it, but the patch got me going quickly. I think the
> > > > > question is whether you want DPDK to support these other ways of
> > > > > linking. I'm certainly not the first to use cgo, since there's a
> > > > > virtual switch project doing the same:
> > > > >
> > > > > https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_lago
> > > > > pu
> > > > > s_vsw&d=DwICAg&c=jcv3orpCsv7C4ly8-ubDoUfrxF5xIGWmptxGWP5vi5w&r=m1RLQ
> > > > > OG
> > > > > Okz9MauvVLZmiGtyWc5mA7DejbPFNE1IDj-4&m=hQqVCNwW7eoEzB_hLFK97i8idS8FI
> > > > > qX oPeclwsIZq7Y&s=BMoBlwkqljwWIBY3SE3pPMCfVnOUlDuZLrno4-SojKM&e=
> > > > >
> > > > > They don't use primary/secondary processes, though, so the issue is
> > > > > never hit. I'm in a situation where using cgo seemed like the easiest
> > > > > path to accomplish what I'm doing since I needed specialized
> > > > > libraries for it that were not available in C/C++. At some point I
> > > > > bet someone would use Cython to start linking against DPDK as well,
> > > > > and we'd likely run into the same issue.> > > >
> > > > >For sure, we want to support using DPDK with cgo or cython.
> > > > >But it is not clear what is the relation with not having the same
> > > > >compilation for primary and secondary. Please could you elaborate?> > >
> > > > Hi Thomas, I think Jean explained it well here:
> > > > https://urldefense.proofpoint.com/v2/url?u=https-3A__dev.dpdk.narkive.
> > > > com_ZM3a7QD1_dpdk-2Ddev-2Dbug-2Dstatic-2Dconstructors-2Dconsidered-2De
> > > > vil&d=DwICAg&c=jcv3orpCsv7C4ly8-ubDoUfrxF5xIGWmptxGWP5vi5w&r=m1RLQOGOk
> > > > z9MauvVLZmiGtyWc5mA7DejbPFNE1IDj-4&m=C69wDgrjDX8_oXp1M_3bnmWOOZdGqwBBG
> > > > 9vzkyGDWGQ&s=YYn2N7WrzJpH1ptNrLZad0nPAQdrUyqBckk2uFuWYPQ&e=
> > > >
> > > > "The build system of the application does not have all the subtelties
> > > > of the DPDK build system, and ends up including *all* the
> > > > constructors, wether they are used or not in the code. Moreover, they
> > > > are included in a different order. Actually, by default the builds
> > > > include no constructors at all (which is a big fail), so the library
> > > > needs to be included with --whole-archive (see Snort DPDK
> > > > instructions)."
> > > >
> > > > I will get to the bottom of my exact case to understand what's
> > > > happening, but my primary application is a cgo application that I'm
> > > > linking to by using almost exactly the same flags that are used in the
> > > > DPDK build system to build examples. The DPDK libraries I'm linking
> > > > against is a single location for both primary and secondary; in other
> > > > words, I don't build DPDK twice.
> > > >
> > > > OK I understand, thanks.
> > > >
> > > > You had alluded to a pkg-config for DPDK in the 2015 thread, which cgo
> > > > can use, but I don't know if that ever was implemented. Cgo can use
> > > > pkg-config if it's available, otherwise the only tools are specifying
> > > > LDFLAGS and CFLAGS into their build system.
> > >Yes, the right answer is still pkg-config :) The good news is that it is now implemented thanks to the meson build system:
> > >     https://urldefense.proofpoint.com/v2/url?u=http-3A__git.dpdk.org_dpdk_tree_doc_build-2Dsdk-2Dmeson.txt-23n182&d=DwICAg&c=jcv3orpCsv7C4ly8-ubDoUfrxF5xIGWmptxGWP5vi5w&r=m1RLQOGOkz9MauvVLZmiGtyWc5mA7DejbPFNE1IDj->4&m=C69wDgrjDX8_oXp1M_3bnmWOOZdGqwBBG9vzkyGDWGQ&s=oC86KD_RJ1T6rfzi3x5zFT1Ri13ELpKmsyFqpgDbgFg&e=
> >
> > Hi Thomas, are there instructions on how to use pkg-config to build the mlx4/5 PMD? I noticed a patch was submitted in September to add support for it, but that link you provided on using meson doesn't say how to build specific drivers. It appears to be disabled by default.
> 
> > If the dependency is found, meson will enable the PMD when building DPDK.
> 
> Do you know where exactly that is? I've been using mlx5 for a while on this system, and I can see that 18.11-rc2 meson build+ninja built the pmd, but it's not on the --libs listing for pkg-config. Does it tell me what I was missing?
> 
For dynamic linking of applications, the drivers are not normally linked
in. Instead, they should be loaded from the drivers directory as .so files
- normally by default in EAL as the driver .so's should be copied to the
EAL_PMD_PATH where EAL finds them automatically. [This applies to both
meson and make builds, though only meson generates the .pc file for
pkg-config]

If you are doing a static build, then you need to explicitly link in the
drivers. You can get a list from pkg-config using the "--static" flag in
this case. A good example of how to use pkg-config in this way can be found
in the Makefiles for most examples, e.g. examples/helloworld/Makefile,
reproduced below.

Regards,
/Bruce

all: shared
.PHONY: shared static
shared: build/$(APP)-shared
        ln -sf $(APP)-shared build/$(APP)
static: build/$(APP)-static
        ln -sf $(APP)-static build/$(APP)

PC_FILE := $(shell pkg-config --path libdpdk)
CFLAGS += -O3 $(shell pkg-config --cflags libdpdk)
LDFLAGS_SHARED = $(shell pkg-config --libs libdpdk)
LDFLAGS_STATIC = -Wl,-Bstatic $(shell pkg-config --static --libs libdpdk)

build/$(APP)-shared: $(SRCS-y) Makefile $(PC_FILE) | build
        $(CC) $(CFLAGS) $(SRCS-y) -o $@ $(LDFLAGS) $(LDFLAGS_SHARED)

build/$(APP)-static: $(SRCS-y) Makefile $(PC_FILE) | build
        $(CC) $(CFLAGS) $(SRCS-y) -o $@ $(LDFLAGS) $(LDFLAGS_STATIC)

build:
        @mkdir -p $@

Re: [dpdk-dev] [PATCH 1/1] eal: Don't fail secondary if primary is missing tailqs

[Burdick, Cliff]

-----Original Message-----
From: Bruce Richardson [mailto:bruce.richardson@intel.com] 
Sent: Wednesday, November 14, 2018 3:48 AM
To: Burdick, Cliff
Cc: Thomas Monjalon; Burakov, Anatoly; dev@dpdk.org
Subject: Re: [dpdk-dev] [PATCH 1/1] eal: Don't fail secondary if primary is missing tailqs

On Tue, Nov 13, 2018 at 11:42:51PM +0000, Burdick, Cliff wrote:
> > 
> > ________________________________________
> > From: Thomas Monjalon [thomas@monjalon.net]
> > Sent: Tuesday, November 13, 2018 2:18 PM
> > To: Burdick, Cliff
> > Cc: Burakov, Anatoly; dev@dpdk.org; bruce.richardson@intel.com
> > Subject: Re: [dpdk-dev] [PATCH 1/1] eal: Don't fail secondary if 
> > primary is missing tailqs
> > 
> > 13/11/2018 23:08, Burdick, Cliff:
> > > From: Thomas Monjalon [mailto:thomas@monjalon.net]
> > > > 13/11/2018 17:38, Burdick, Cliff:
> > > > > From: Thomas Monjalon [mailto:thomas@monjalon.net]
> > > > > 13/11/2018 16:45, Burdick, Cliff:
> > > > > > From: Burakov, Anatoly [mailto:anatoly.burakov@intel.com]
> > > > > > > On 13-Nov-18 9:21 AM, Thomas Monjalon wrote:
> > > > > > > > 13/11/2018 00:33, Burdick, Cliff:
> > > > > > > >> This patch was submitted by Jean Tourrilhes over two 
> > > > > > > >> years ago, but didn't receive any responses. I hit the 
> > > > > > > >> same issue recently when trying to use cgo (Golang) as a 
> > > > > > > >> primary process linked to libdpdk.a against a C++ 
> > > > > > > >> application linked against the same library.> > >
> > > > > > > >
> > > > > > > > The question is to know why you don't have the same 
> > > > > > > > constructors in primary and seconday?
> > > > > > >
> > > > > > > I've hit similar things in the past. I believe it was caused 
> > > > > > > by our build system stripping out unused libraries (such as 
> > > > > > > rte_hash) from the binary and thus not calling the 
> > > > > > > constructor in the primary, but doing so in the secondary 
> > > > > > > (or something to that effect). In any case, this is caused 
> > > > > > > by linking different number of libraries to primary and 
> > > > > > > secondary, and should probably be fixed in the build system, 
> > > > > > > not in the tailqs code (unless we specifically support 
> > > > > > > having different linked libraries to primary and 
> > > > > > > secondary?).> > > >
> > > > > > Right, I think the original author of the patch stated the 
> > > > > > reasons in the link I provided. The build system seems like 
> > > > > > the most appropriate place to fix it, but the patch got me 
> > > > > > going quickly. I think the question is whether you want DPDK 
> > > > > > to support these other ways of linking. I'm certainly not the 
> > > > > > first to use cgo, since there's a virtual switch project doing the same:
> > > > > >
> > > > > > https://urldefense.proofpoint.com/v2/url?u=https-3A__github.co
> > > > > > m_lago
> > > > > > pu
> > > > > > s_vsw&d=DwICAg&c=jcv3orpCsv7C4ly8-ubDoUfrxF5xIGWmptxGWP5vi5w&r
> > > > > > =m1RLQ
> > > > > > OG
> > > > > > Okz9MauvVLZmiGtyWc5mA7DejbPFNE1IDj-4&m=hQqVCNwW7eoEzB_hLFK97i8
> > > > > > idS8FI qX 
> > > > > > oPeclwsIZq7Y&s=BMoBlwkqljwWIBY3SE3pPMCfVnOUlDuZLrno4-SojKM&e=
> > > > > >
> > > > > > They don't use primary/secondary processes, though, so the 
> > > > > >issue is  never hit. I'm in a situation where using cgo seemed 
> > > > > >like the easiest  path to accomplish what I'm doing since I 
> > > > > >needed specialized  libraries for it that were not available in 
> > > > > >C/C++. At some point I  bet someone would use Cython to start 
> > > > > >linking against DPDK as well,  and we'd likely run into the 
> > > > > >same issue.> > > > For sure, we want to support using DPDK with cgo or cython.
> > > > > >But it is not clear what is the relation with not having the 
> > > > > >same compilation for primary and secondary. Please could you 
> > > > > >elaborate?> > >
> > > > > Hi Thomas, I think Jean explained it well here:
> > > > > https://urldefense.proofpoint.com/v2/url?u=https-3A__dev.dpdk.narkive.
> > > > > com_ZM3a7QD1_dpdk-2Ddev-2Dbug-2Dstatic-2Dconstructors-2Dconsider
> > > > > ed-2De 
> > > > > vil&d=DwICAg&c=jcv3orpCsv7C4ly8-ubDoUfrxF5xIGWmptxGWP5vi5w&r=m1R
> > > > > LQOGOk 
> > > > > z9MauvVLZmiGtyWc5mA7DejbPFNE1IDj-4&m=C69wDgrjDX8_oXp1M_3bnmWOOZd
> > > > > GqwBBG 
> > > > > 9vzkyGDWGQ&s=YYn2N7WrzJpH1ptNrLZad0nPAQdrUyqBckk2uFuWYPQ&e=
> > > > >
> > > > > "The build system of the application does not have all the 
> > > > > subtelties of the DPDK build system, and ends up including *all* 
> > > > > the constructors, wether they are used or not in the code. 
> > > > > Moreover, they are included in a different order. Actually, by 
> > > > > default the builds include no constructors at all (which is a 
> > > > > big fail), so the library needs to be included with 
> > > > > --whole-archive (see Snort DPDK instructions)."
> > > > >
> > > > > I will get to the bottom of my exact case to understand what's 
> > > > > happening, but my primary application is a cgo application that 
> > > > > I'm linking to by using almost exactly the same flags that are 
> > > > > used in the DPDK build system to build examples. The DPDK 
> > > > > libraries I'm linking against is a single location for both 
> > > > > primary and secondary; in other words, I don't build DPDK twice.
> > > > >
> > > > > OK I understand, thanks.
> > > > >
> > > > > You had alluded to a pkg-config for DPDK in the 2015 thread, 
> > > > > which cgo can use, but I don't know if that ever was 
> > > > > implemented. Cgo can use pkg-config if it's available, otherwise 
> > > > > the only tools are specifying LDFLAGS and CFLAGS into their build system.
> > > >Yes, the right answer is still pkg-config :) The good news is that it is now implemented thanks to the meson build system:
> > > >     
> > > >https://urldefense.proofpoint.com/v2/url?u=http-3A__git.dpdk.org_dp
> > > >dk_tree_doc_build-2Dsdk-2Dmeson.txt-23n182&d=DwICAg&c=jcv3orpCsv7C4
> > > >ly8-ubDoUfrxF5xIGWmptxGWP5vi5w&r=m1RLQOGOkz9MauvVLZmiGtyWc5mA7DejbP
> > > >FNE1IDj->4&m=C69wDgrjDX8_oXp1M_3bnmWOOZdGqwBBG9vzkyGDWGQ&s=oC86KD_R
> > > >J1T6rfzi3x5zFT1Ri13ELpKmsyFqpgDbgFg&e=
> > >
> > > Hi Thomas, are there instructions on how to use pkg-config to build the mlx4/5 PMD? I noticed a patch was submitted in September to add support for it, but that link you provided on using meson doesn't say how to build specific drivers. It appears to be disabled by default.
> > 
> > > If the dependency is found, meson will enable the PMD when building DPDK.
> > 
> > Do you know where exactly that is? I've been using mlx5 for a while on this system, and I can see that 18.11-rc2 meson build+ninja built the pmd, but it's not on the --libs listing for pkg-config. Does it tell me what I was missing?
> > 
> For dynamic linking of applications, the drivers are not normally linked in. Instead, they should be loaded from the drivers directory as .so files
> - normally by default in EAL as the driver .so's should be copied to the EAL_PMD_PATH where EAL finds them automatically. [This applies to both meson and make builds, though only meson generates the .pc file for pkg-config]
> 
> If you are doing a static build, then you need to explicitly link in the drivers. You can get a list from pkg-config using the "--static" flag in this case. A good example of how to use pkg-config in this way can be found in the Makefiles for most examples, e.g. examples/helloworld/Makefile, reproduced below.
> 
> Regards,
> /Bruce
> 
> all: shared
> .PHONY: shared static
> shared: build/$(APP)-shared
>         ln -sf $(APP)-shared build/$(APP)
> static: build/$(APP)-static
>         ln -sf $(APP)-static build/$(APP)
> 
> PC_FILE := $(shell pkg-config --path libdpdk) CFLAGS += -O3 $(shell pkg-config --cflags libdpdk) LDFLAGS_SHARED = $(shell pkg-config --libs libdpdk) LDFLAGS_STATIC = -Wl,-Bstatic $(shell pkg-config --static --libs libdpdk)
> 
> build/$(APP)-shared: $(SRCS-y) Makefile $(PC_FILE) | build
>         $(CC) $(CFLAGS) $(SRCS-y) -o $@ $(LDFLAGS) $(LDFLAGS_SHARED)
> 
> build/$(APP)-static: $(SRCS-y) Makefile $(PC_FILE) | build
>         $(CC) $(CFLAGS) $(SRCS-y) -o $@ $(LDFLAGS) $(LDFLAGS_STATIC)
> 
> build:
>         @mkdir -p $@

Thanks Bruce. I tried getting this to compile using cgo, and it's causing more pain than it's worth. I used the --static --libs options, and there were still numerous linker errors, some specific to mlx, and some not. Specifically libmlx5 and libmnl are both needed, but they're not part of the linker line from pkg-config. At this point I'll just break the Go application up into a separate C application that handles all the DPDK parts, and send messages between them.

Re: [dpdk-dev] [PATCH 1/1] eal: Don't fail secondary if primary is missing tailqs

[Luca Boccassi]

On Wed, 2018-11-14 at 17:40 +0000, Burdick, Cliff wrote:
> 
> -----Original Message-----
> From: Bruce Richardson [mailto:bruce.richardson@intel.com] 
> Sent: Wednesday, November 14, 2018 3:48 AM
> To: Burdick, Cliff
> Cc: Thomas Monjalon; Burakov, Anatoly; dev@dpdk.org
> Subject: Re: [dpdk-dev] [PATCH 1/1] eal: Don't fail secondary if
> primary is missing tailqs
> 
> On Tue, Nov 13, 2018 at 11:42:51PM +0000, Burdick, Cliff wrote:
> > > 
> > > ________________________________________
> > > From: Thomas Monjalon [thomas@monjalon.net]
> > > Sent: Tuesday, November 13, 2018 2:18 PM
> > > To: Burdick, Cliff
> > > Cc: Burakov, Anatoly; dev@dpdk.org; bruce.richardson@intel.com
> > > Subject: Re: [dpdk-dev] [PATCH 1/1] eal: Don't fail secondary if 
> > > primary is missing tailqs
> > > 
> > > 13/11/2018 23:08, Burdick, Cliff:
> > > > From: Thomas Monjalon [mailto:thomas@monjalon.net]
> > > > > 13/11/2018 17:38, Burdick, Cliff:
> > > > > > From: Thomas Monjalon [mailto:thomas@monjalon.net]
> > > > > > 13/11/2018 16:45, Burdick, Cliff:
> > > > > > > From: Burakov, Anatoly [mailto:anatoly.burakov@intel.com]
> > > > > > > > On 13-Nov-18 9:21 AM, Thomas Monjalon wrote:
> > > > > > > > > 13/11/2018 00:33, Burdick, Cliff:
> > > > > > > > > > This patch was submitted by Jean Tourrilhes over
> > > > > > > > > > two 
> > > > > > > > > > years ago, but didn't receive any responses. I hit
> > > > > > > > > > the 
> > > > > > > > > > same issue recently when trying to use cgo (Golang)
> > > > > > > > > > as a 
> > > > > > > > > > primary process linked to libdpdk.a against a C++ 
> > > > > > > > > > application linked against the same library.> > >
> > > > > > > > > 
> > > > > > > > > The question is to know why you don't have the same 
> > > > > > > > > constructors in primary and seconday?
> > > > > > > > 
> > > > > > > > I've hit similar things in the past. I believe it was
> > > > > > > > caused 
> > > > > > > > by our build system stripping out unused libraries
> > > > > > > > (such as 
> > > > > > > > rte_hash) from the binary and thus not calling the 
> > > > > > > > constructor in the primary, but doing so in the
> > > > > > > > secondary 
> > > > > > > > (or something to that effect). In any case, this is
> > > > > > > > caused 
> > > > > > > > by linking different number of libraries to primary
> > > > > > > > and 
> > > > > > > > secondary, and should probably be fixed in the build
> > > > > > > > system, 
> > > > > > > > not in the tailqs code (unless we specifically support 
> > > > > > > > having different linked libraries to primary and 
> > > > > > > > secondary?).> > > >
> > > > > > > 
> > > > > > > Right, I think the original author of the patch stated
> > > > > > > the 
> > > > > > > reasons in the link I provided. The build system seems
> > > > > > > like 
> > > > > > > the most appropriate place to fix it, but the patch got
> > > > > > > me 
> > > > > > > going quickly. I think the question is whether you want
> > > > > > > DPDK 
> > > > > > > to support these other ways of linking. I'm certainly not
> > > > > > > the 
> > > > > > > first to use cgo, since there's a virtual switch project
> > > > > > > doing the same:
> > > > > > > 
> > > > > > > https://urldefense.proofpoint.com/v2/url?u=https-3A__gith
> > > > > > > ub.co
> > > > > > > m_lago
> > > > > > > pu
> > > > > > > s_vsw&d=DwICAg&c=jcv3orpCsv7C4ly8-
> > > > > > > ubDoUfrxF5xIGWmptxGWP5vi5w&r
> > > > > > > =m1RLQ
> > > > > > > OG
> > > > > > > Okz9MauvVLZmiGtyWc5mA7DejbPFNE1IDj-
> > > > > > > 4&m=hQqVCNwW7eoEzB_hLFK97i8
> > > > > > > idS8FI qX 
> > > > > > > oPeclwsIZq7Y&s=BMoBlwkqljwWIBY3SE3pPMCfVnOUlDuZLrno4-
> > > > > > > SojKM&e=
> > > > > > > 
> > > > > > > They don't use primary/secondary processes, though, so
> > > > > > > the 
> > > > > > > issue is  never hit. I'm in a situation where using cgo
> > > > > > > seemed 
> > > > > > > like the easiest  path to accomplish what I'm doing since
> > > > > > > I 
> > > > > > > needed specialized  libraries for it that were not
> > > > > > > available in 
> > > > > > > C/C++. At some point I  bet someone would use Cython to
> > > > > > > start 
> > > > > > > linking against DPDK as well,  and we'd likely run into
> > > > > > > the 
> > > > > > > same issue.> > > > For sure, we want to support using
> > > > > > > DPDK with cgo or cython.
> > > > > > > But it is not clear what is the relation with not having
> > > > > > > the 
> > > > > > > same compilation for primary and secondary. Please could
> > > > > > > you 
> > > > > > > elaborate?> > >
> > > > > > 
> > > > > > Hi Thomas, I think Jean explained it well here:
> > > > > > https://urldefense.proofpoint.com/v2/url?u=https-3A__dev.dp
> > > > > > dk.narkive.
> > > > > > com_ZM3a7QD1_dpdk-2Ddev-2Dbug-2Dstatic-2Dconstructors-
> > > > > > 2Dconsider
> > > > > > ed-2De 
> > > > > > vil&d=DwICAg&c=jcv3orpCsv7C4ly8-
> > > > > > ubDoUfrxF5xIGWmptxGWP5vi5w&r=m1R
> > > > > > LQOGOk 
> > > > > > z9MauvVLZmiGtyWc5mA7DejbPFNE1IDj-
> > > > > > 4&m=C69wDgrjDX8_oXp1M_3bnmWOOZd
> > > > > > GqwBBG 
> > > > > > 9vzkyGDWGQ&s=YYn2N7WrzJpH1ptNrLZad0nPAQdrUyqBckk2uFuWYPQ&e=
> > > > > > 
> > > > > > "The build system of the application does not have all the 
> > > > > > subtelties of the DPDK build system, and ends up including
> > > > > > *all* 
> > > > > > the constructors, wether they are used or not in the code. 
> > > > > > Moreover, they are included in a different order. Actually,
> > > > > > by 
> > > > > > default the builds include no constructors at all (which is
> > > > > > a 
> > > > > > big fail), so the library needs to be included with 
> > > > > > --whole-archive (see Snort DPDK instructions)."
> > > > > > 
> > > > > > I will get to the bottom of my exact case to understand
> > > > > > what's 
> > > > > > happening, but my primary application is a cgo application
> > > > > > that 
> > > > > > I'm linking to by using almost exactly the same flags that
> > > > > > are 
> > > > > > used in the DPDK build system to build examples. The DPDK 
> > > > > > libraries I'm linking against is a single location for
> > > > > > both 
> > > > > > primary and secondary; in other words, I don't build DPDK
> > > > > > twice.
> > > > > > 
> > > > > > OK I understand, thanks.
> > > > > > 
> > > > > > You had alluded to a pkg-config for DPDK in the 2015
> > > > > > thread, 
> > > > > > which cgo can use, but I don't know if that ever was 
> > > > > > implemented. Cgo can use pkg-config if it's available,
> > > > > > otherwise 
> > > > > > the only tools are specifying LDFLAGS and CFLAGS into their
> > > > > > build system.
> > > > > 
> > > > > Yes, the right answer is still pkg-config :) The good news is
> > > > > that it is now implemented thanks to the meson build system:
> > > > >     
> > > > > https://urldefense.proofpoint.com/v2/url?u=http-3A__git.dpdk.
> > > > > org_dp
> > > > > dk_tree_doc_build-2Dsdk-2Dmeson.txt-
> > > > > 23n182&d=DwICAg&c=jcv3orpCsv7C4
> > > > > ly8-
> > > > > ubDoUfrxF5xIGWmptxGWP5vi5w&r=m1RLQOGOkz9MauvVLZmiGtyWc5mA7Dej
> > > > > bP
> > > > > FNE1IDj-
> > > > > >4&m=C69wDgrjDX8_oXp1M_3bnmWOOZdGqwBBG9vzkyGDWGQ&s=oC86KD_R
> > > > > J1T6rfzi3x5zFT1Ri13ELpKmsyFqpgDbgFg&e=
> > > > 
> > > > Hi Thomas, are there instructions on how to use pkg-config to
> > > > build the mlx4/5 PMD? I noticed a patch was submitted in
> > > > September to add support for it, but that link you provided on
> > > > using meson doesn't say how to build specific drivers. It
> > > > appears to be disabled by default.
> > > > If the dependency is found, meson will enable the PMD when
> > > > building DPDK.
> > > 
> > > Do you know where exactly that is? I've been using mlx5 for a
> > > while on this system, and I can see that 18.11-rc2 meson
> > > build+ninja built the pmd, but it's not on the --libs listing for
> > > pkg-config. Does it tell me what I was missing?
> > > 
> > 
> > For dynamic linking of applications, the drivers are not normally
> > linked in. Instead, they should be loaded from the drivers
> > directory as .so files
> > - normally by default in EAL as the driver .so's should be copied
> > to the EAL_PMD_PATH where EAL finds them automatically. [This
> > applies to both meson and make builds, though only meson generates
> > the .pc file for pkg-config]
> > 
> > If you are doing a static build, then you need to explicitly link
> > in the drivers. You can get a list from pkg-config using the "
> > --static" flag in this case. A good example of how to use pkg-
> > config in this way can be found in the Makefiles for most examples,
> > e.g. examples/helloworld/Makefile, reproduced below.
> > 
> > Regards,
> > /Bruce
> > 
> > all: shared
> > .PHONY: shared static
> > shared: build/$(APP)-shared
> >         ln -sf $(APP)-shared build/$(APP)
> > static: build/$(APP)-static
> >         ln -sf $(APP)-static build/$(APP)
> > 
> > PC_FILE := $(shell pkg-config --path libdpdk) CFLAGS += -O3 $(shell
> > pkg-config --cflags libdpdk) LDFLAGS_SHARED = $(shell pkg-config --
> > libs libdpdk) LDFLAGS_STATIC = -Wl,-Bstatic $(shell pkg-config --
> > static --libs libdpdk)
> > 
> > build/$(APP)-shared: $(SRCS-y) Makefile $(PC_FILE) | build
> >         $(CC) $(CFLAGS) $(SRCS-y) -o $@ $(LDFLAGS)
> > $(LDFLAGS_SHARED)
> > 
> > build/$(APP)-static: $(SRCS-y) Makefile $(PC_FILE) | build
> >         $(CC) $(CFLAGS) $(SRCS-y) -o $@ $(LDFLAGS)
> > $(LDFLAGS_STATIC)
> > 
> > build:
> >         @mkdir -p $@
> 
> Thanks Bruce. I tried getting this to compile using cgo, and it's
> causing more pain than it's worth. I used the --static --libs
> options, and there were still numerous linker errors, some specific
> to mlx, and some not. Specifically libmlx5 and libmnl are both
> needed, but they're not part of the linker line from pkg-config. At
> this point I'll just break the Go application up into a separate C
> application that handles all the DPDK parts, and send messages
> between them.

Hi,

As far as I can see, both mnl and mlx5 (and all the other reverse
dependencies) are listed correctly in the libdpdk.pc Libs.private
entry, and pkg-config --libs --static libdpdk.pc does print them as
intended. This is with 18.11-rc3.
Are you sure everything is correct (pkg-config path is right, --static
is used, etc)?

-- 
Kind regards,
Luca Boccassi

Re: [dpdk-dev] [PATCH 1/1] eal: Don't fail secondary if primary is missing tailqs

[Burdick, Cliff]

-----Original Message-----
From: Luca Boccassi [mailto:bluca@debian.org] 
Sent: Wednesday, November 14, 2018 10:15 AM
To: Burdick, Cliff; Bruce Richardson
Cc: Thomas Monjalon; Burakov, Anatoly; dev@dpdk.org
Subject: Re: [dpdk-dev] [PATCH 1/1] eal: Don't fail secondary if primary is missing tailqs

> On Wed, 2018-11-14 at 17:40 +0000, Burdick, Cliff wrote:
> > 
> > -----Original Message-----
> > From: Bruce Richardson [mailto:bruce.richardson@intel.com]
> > Sent: Wednesday, November 14, 2018 3:48 AM
> > To: Burdick, Cliff
> > Cc: Thomas Monjalon; Burakov, Anatoly; dev@dpdk.org
> > Subject: Re: [dpdk-dev] [PATCH 1/1] eal: Don't fail secondary if 
> > primary is missing tailqs
> > 
> > On Tue, Nov 13, 2018 at 11:42:51PM +0000, Burdick, Cliff wrote:
> > > > 
> > > > ________________________________________
> > > > From: Thomas Monjalon [thomas@monjalon.net]
> > > > Sent: Tuesday, November 13, 2018 2:18 PM
> > > > To: Burdick, Cliff
> > > > Cc: Burakov, Anatoly; dev@dpdk.org; bruce.richardson@intel.com
> > > > Subject: Re: [dpdk-dev] [PATCH 1/1] eal: Don't fail secondary if 
> > > > primary is missing tailqs
> > > > 
> > > > 13/11/2018 23:08, Burdick, Cliff:
> > > > > From: Thomas Monjalon [mailto:thomas@monjalon.net]
> > > > > > 13/11/2018 17:38, Burdick, Cliff:
> > > > > > > From: Thomas Monjalon [mailto:thomas@monjalon.net]
> > > > > > > 13/11/2018 16:45, Burdick, Cliff:
> > > > > > > > From: Burakov, Anatoly [mailto:anatoly.burakov@intel.com]
> > > > > > > > > On 13-Nov-18 9:21 AM, Thomas Monjalon wrote:
> > > > > > > > > > 13/11/2018 00:33, Burdick, Cliff:
> > > > > > > > > > > This patch was submitted by Jean Tourrilhes over two 
> > > > > > > > > > > years ago, but didn't receive any responses. I hit 
> > > > > > > > > > > the same issue recently when trying to use cgo 
> > > > > > > > > > > (Golang) as a primary process linked to libdpdk.a 
> > > > > > > > > > > against a C++ application linked against the same 
> > > > > > > > > > > library.> > >
> > > > > > > > > > 
> > > > > > > > > > The question is to know why you don't have the same 
> > > > > > > > > > constructors in primary and seconday?
> > > > > > > > > 
> > > > > > > > > I've hit similar things in the past. I believe it was 
> > > > > > > > > caused by our build system stripping out unused 
> > > > > > > > > libraries (such as
> > > > > > > > > rte_hash) from the binary and thus not calling the 
> > > > > > > > > constructor in the primary, but doing so in the 
> > > > > > > > > secondary (or something to that effect). In any case, 
> > > > > > > > > this is caused by linking different number of libraries 
> > > > > > > > > to primary and secondary, and should probably be fixed 
> > > > > > > > > in the build system, not in the tailqs code (unless we 
> > > > > > > > > specifically support having different linked libraries 
> > > > > > > > > to primary and secondary?).> > > >
> > > > > > > > 
> > > > > > > > Right, I think the original author of the patch stated the 
> > > > > > > > reasons in the link I provided. The build system seems 
> > > > > > > > like the most appropriate place to fix it, but the patch 
> > > > > > > > got me going quickly. I think the question is whether you 
> > > > > > > > want DPDK to support these other ways of linking. I'm 
> > > > > > > > certainly not the first to use cgo, since there's a 
> > > > > > > > virtual switch project doing the same:
> > > > > > > > 
> > > > > > > > https://urldefense.proofpoint.com/v2/url?u=https-3A__gith
> > > > > > > > ub.co
> > > > > > > > m_lago
> > > > > > > > pu
> > > > > > > > s_vsw&d=DwICAg&c=jcv3orpCsv7C4ly8-
> > > > > > > > ubDoUfrxF5xIGWmptxGWP5vi5w&r =m1RLQ OG
> > > > > > > > Okz9MauvVLZmiGtyWc5mA7DejbPFNE1IDj-
> > > > > > > > 4&m=hQqVCNwW7eoEzB_hLFK97i8 idS8FI qX
> > > > > > > > oPeclwsIZq7Y&s=BMoBlwkqljwWIBY3SE3pPMCfVnOUlDuZLrno4-
> > > > > > > > SojKM&e=
> > > > > > > > 
> > > > > > > > They don't use primary/secondary processes, though, so the 
> > > > > > > > issue is  never hit. I'm in a situation where using cgo 
> > > > > > > > seemed like the easiest  path to accomplish what I'm doing 
> > > > > > > > since I needed specialized  libraries for it that were not 
> > > > > > > > available in C/C++. At some point I  bet someone would use 
> > > > > > > > Cython to start linking against DPDK as well,  and we'd 
> > > > > > > > likely run into the same issue.> > > > For sure, we want 
> > > > > > > > to support using DPDK with cgo or cython.
> > > > > > > > But it is not clear what is the relation with not having 
> > > > > > > > the same compilation for primary and secondary. Please 
> > > > > > > > could you elaborate?> > >
> > > > > > > 
> > > > > > > Hi Thomas, I think Jean explained it well here:
> > > > > > > https://urldefense.proofpoint.com/v2/url?u=https-3A__dev.dp
> > > > > > > dk.narkive.
> > > > > > > com_ZM3a7QD1_dpdk-2Ddev-2Dbug-2Dstatic-2Dconstructors-
> > > > > > > 2Dconsider
> > > > > > > ed-2De
> > > > > > > vil&d=DwICAg&c=jcv3orpCsv7C4ly8- 
> > > > > > > ubDoUfrxF5xIGWmptxGWP5vi5w&r=m1R LQOGOk
> > > > > > > z9MauvVLZmiGtyWc5mA7DejbPFNE1IDj- 
> > > > > > > 4&m=C69wDgrjDX8_oXp1M_3bnmWOOZd GqwBBG 
> > > > > > > 9vzkyGDWGQ&s=YYn2N7WrzJpH1ptNrLZad0nPAQdrUyqBckk2uFuWYPQ&e=
> > > > > > > 
> > > > > > > "The build system of the application does not have all the 
> > > > > > > subtelties of the DPDK build system, and ends up including
> > > > > > > *all*
> > > > > > > the constructors, wether they are used or not in the code. 
> > > > > > > Moreover, they are included in a different order. Actually, 
> > > > > > > by default the builds include no constructors at all (which 
> > > > > > > is a big fail), so the library needs to be included with 
> > > > > > > --whole-archive (see Snort DPDK instructions)."
> > > > > > > 
> > > > > > > I will get to the bottom of my exact case to understand 
> > > > > > > what's happening, but my primary application is a cgo 
> > > > > > > application that I'm linking to by using almost exactly the 
> > > > > > > same flags that are used in the DPDK build system to build 
> > > > > > > examples. The DPDK libraries I'm linking against is a single 
> > > > > > > location for both primary and secondary; in other words, I 
> > > > > > > don't build DPDK twice.
> > > > > > > 
> > > > > > > OK I understand, thanks.
> > > > > > > 
> > > > > > > You had alluded to a pkg-config for DPDK in the 2015 thread, 
> > > > > > > which cgo can use, but I don't know if that ever was 
> > > > > > > implemented. Cgo can use pkg-config if it's available, 
> > > > > > > otherwise the only tools are specifying LDFLAGS and CFLAGS 
> > > > > > > into their build system.
> > > > > > 
> > > > > > Yes, the right answer is still pkg-config :) The good news is 
> > > > > > that it is now implemented thanks to the meson build system:
> > > > > >     
> > > > > > https://urldefense.proofpoint.com/v2/url?u=http-3A__git.dpdk.
> > > > > > org_dp
> > > > > > dk_tree_doc_build-2Dsdk-2Dmeson.txt-
> > > > > > 23n182&d=DwICAg&c=jcv3orpCsv7C4
> > > > > > ly8-
> > > > > > ubDoUfrxF5xIGWmptxGWP5vi5w&r=m1RLQOGOkz9MauvVLZmiGtyWc5mA7Dej
> > > > > > bP
> > > > > > FNE1IDj-
> > > > > > >4&m=C69wDgrjDX8_oXp1M_3bnmWOOZdGqwBBG9vzkyGDWGQ&s=oC86KD_R
> > > > > > J1T6rfzi3x5zFT1Ri13ELpKmsyFqpgDbgFg&e=
> > > > > 
> > > > > Hi Thomas, are there instructions on how to use pkg-config to 
> > > > > build the mlx4/5 PMD? I noticed a patch was submitted in 
> > > > > September to add support for it, but that link you provided on 
> > > > > using meson doesn't say how to build specific drivers. It 
> > > > > appears to be disabled by default.
> > > > > If the dependency is found, meson will enable the PMD when 
> > > > > building DPDK.
> > > > 
> > > > Do you know where exactly that is? I've been using mlx5 for a 
> > > > while on this system, and I can see that 18.11-rc2 meson
> > > > build+ninja built the pmd, but it's not on the --libs listing for
> > > > pkg-config. Does it tell me what I was missing?
> > > > 
> > > 
> > > For dynamic linking of applications, the drivers are not normally 
> > > linked in. Instead, they should be loaded from the drivers directory 
> > > as .so files
> > > - normally by default in EAL as the driver .so's should be copied to 
> > > the EAL_PMD_PATH where EAL finds them automatically. [This applies 
> > > to both meson and make builds, though only meson generates the .pc 
> > > file for pkg-config]
> > > 
> > > If you are doing a static build, then you need to explicitly link in 
> > > the drivers. You can get a list from pkg-config using the "
> > > --static" flag in this case. A good example of how to use pkg- 
> > > config in this way can be found in the Makefiles for most examples, 
> > > e.g. examples/helloworld/Makefile, reproduced below.
> > > 
> > > Regards,
> > > /Bruce
> > > 
> > > all: shared
> > > .PHONY: shared static
> > > shared: build/$(APP)-shared
> > >         ln -sf $(APP)-shared build/$(APP)
> > > static: build/$(APP)-static
> > >         ln -sf $(APP)-static build/$(APP)
> > > 
> > > PC_FILE := $(shell pkg-config --path libdpdk) CFLAGS += -O3 $(shell 
> > > pkg-config --cflags libdpdk) LDFLAGS_SHARED = $(shell pkg-config -- 
> > > libs libdpdk) LDFLAGS_STATIC = -Wl,-Bstatic $(shell pkg-config -- 
> > > static --libs libdpdk)
> > > 
> > > build/$(APP)-shared: $(SRCS-y) Makefile $(PC_FILE) | build
> > >         $(CC) $(CFLAGS) $(SRCS-y) -o $@ $(LDFLAGS)
> > > $(LDFLAGS_SHARED)
> > > 
> > > build/$(APP)-static: $(SRCS-y) Makefile $(PC_FILE) | build
> > >         $(CC) $(CFLAGS) $(SRCS-y) -o $@ $(LDFLAGS)
> > > $(LDFLAGS_STATIC)
> > > 
> > > build:
> > >         @mkdir -p $@
> > 
> > Thanks Bruce. I tried getting this to compile using cgo, and it's 
> > causing more pain than it's worth. I used the --static --libs options, 
> > and there were still numerous linker errors, some specific to mlx, and 
> > some not. Specifically libmlx5 and libmnl are both needed, but they're 
> > not part of the linker line from pkg-config. At this point I'll just 
> > break the Go application up into a separate C application that handles 
> > all the DPDK parts, and send messages between them.
> 
> Hi,
> 
> As far as I can see, both mnl and mlx5 (and all the other reverse
> dependencies) are listed correctly in the libdpdk.pc Libs.private entry, and pkg-config --libs --static libdpdk.pc does print them as intended. This is with 18.11-rc3.
> Are you sure everything is correct (pkg-config path is right, --static is used, etc)?
> 
> --
> Kind regards,
> Luca Boccassi

Hi Luca, here is what pkg-config gives:

PKG_CONFIG_PATH=meson-private/ pkg-config --libs --static libdpdk
-L/usr/local/lib/x86_64-linux-gnu -lrte_eventdev -lrte_power -lrte_ip_frag -lrte_hash -lrte_pdump -lrte_eal -lrte_pipeline -lrte_table -lrte_bbdev -lrte_bpf -lrte_vhost -lrte_metrics -lrte_jobstats -lrte_net -lrte_reorder -lrte_ring -lrte_mempool -lrte_security -lrte_compressdev -lrte_rawdev -lrte_mbuf -lrte_kvargs -lrte_port -lrte_pci -lrte_ethdev -lrte_gro -lrte_gso -lrte_cryptodev -lrte_sched -lrte_latencystats -lrte_efd -lrte_distributor -lrte_meter -lrte_acl -lrte_member -lrte_cmdline -lrte_lpm -lrte_kni -lrte_cfgfile -lrte_bitratestats -lrte_timer -lrte_flow_classify -lrte_mempool_bucket -lrte_pmd_null_crypto -lrte_pmd_failsafe -lrte_bus_ifpga -lrte_pmd_atlantic -lrte_pmd_mlx4 -lrte_pmd_vmxnet3 -lrte_pmd_avp -lrte_common_dpaax -lrte_pmd_ena -lcrypto -lrte_bus_fslmc -ldl -lrte_pmd_avf -lrte_pmd_crypto_scheduler -lrte_pmd_netvsc -lrte_pmd_vhost -lrte_bus_dpaa -lrte_mempool_dpaa2 -lrte_common_octeontx -lrte_pmd_liquidio -lrte_pmd_ifc -Wl,-Bdynamic -lnuma -lrte_pmd_enic -lrte_common_cpt -pthread -lrte_pmd_octeontx_crypto -lrte_pmd_qat -lrte_bus_vmbus -lrte_pmd_null -lm -lrte_pmd_dpaa -lrte_bus_vdev -lrte_pmd_dpaa2 -lrte_pmd_skeleton_event -lrte_pmd_af_packet -lrte_pmd_octeontx -lrte_pmd_thunderx -lrte_pmd_ring -lrte_pmd_octeontx_event -lrte_pmd_sw_event -lrte_pmd_ark -lrte_mempool_octeontx -lrte_pmd_ixgbe -lrte_pmd_kni -lrte_mempool_ring -lrte_pmd_virtio_crypto -lrte_mempool_dpaa -lrte_pmd_dpaa2_cmdif -lrte_bus_pci -lrte_pmd_opdl_event -lrte_pmd_mlx5 -lrte_pmd_virtio -lrte_pmd_tap -lrte_pmd_caam_jr -lrte_pmd_dpaa2_sec -lrte_pmd_dpaa2_qdma -lrte_pmd_enetc -lrte_pmd_sfc -lrte_pmd_bnxt -lrte_pmd_dpaa2_event -lrte_pmd_cxgbe -Wl,--whole-archive -Wl,--no-as-needed -lrte_pmd_e1000 -lrte_pmd_softnic -lrte_pmd_bond -lrte_pmd_fm10k -lrte_pmd_i40e -lrte_pmd_nfp -lrte_pmd_qede -Wl,--no-whole-archive -lrte_pmd_axgbe -lrte_pmd_ccp -lrte_pmd_ifpga_rawdev -lrte_pmd_bbdev_null -lrte_pmd_openssl -lrte_pmd_dsw_event -lrte_pmd_dpaa_event -lrte_mempool_stack -lrte_pmd_vdev_netvsc -lrte_pmd_dpaa_sec -lrte_pmd_skeleton_rawdev -lrte_pmd_octeontx_compress

You'll notice there's no mlx5 or mnl in that list. I was using 18.11-rc2 since I cloned early yesterday. Perhaps meson determined not to put it in there for some reason?

Re: [dpdk-dev] [PATCH 1/1] eal: Don't fail secondary if primary is missing tailqs

[Luca Boccassi]

On Wed, 2018-11-14 at 18:24 +0000, Burdick, Cliff wrote:
> 
> -----Original Message-----
> From: Luca Boccassi [mailto:bluca@debian.org] 
> Sent: Wednesday, November 14, 2018 10:15 AM
> To: Burdick, Cliff; Bruce Richardson
> Cc: Thomas Monjalon; Burakov, Anatoly; dev@dpdk.org
> Subject: Re: [dpdk-dev] [PATCH 1/1] eal: Don't fail secondary if
> primary is missing tailqs
> 
> > On Wed, 2018-11-14 at 17:40 +0000, Burdick, Cliff wrote:
> > > 
> > > -----Original Message-----
> > > From: Bruce Richardson [mailto:bruce.richardson@intel.com]
> > > Sent: Wednesday, November 14, 2018 3:48 AM
> > > To: Burdick, Cliff
> > > Cc: Thomas Monjalon; Burakov, Anatoly; dev@dpdk.org
> > > Subject: Re: [dpdk-dev] [PATCH 1/1] eal: Don't fail secondary if 
> > > primary is missing tailqs
> > > 
> > > On Tue, Nov 13, 2018 at 11:42:51PM +0000, Burdick, Cliff wrote:
> > > > > 
> > > > > ________________________________________
> > > > > From: Thomas Monjalon [thomas@monjalon.net]
> > > > > Sent: Tuesday, November 13, 2018 2:18 PM
> > > > > To: Burdick, Cliff
> > > > > Cc: Burakov, Anatoly; dev@dpdk.org; bruce.richardson@intel.co
> > > > > m
> > > > > Subject: Re: [dpdk-dev] [PATCH 1/1] eal: Don't fail secondary
> > > > > if 
> > > > > primary is missing tailqs
> > > > > 
> > > > > 13/11/2018 23:08, Burdick, Cliff:
> > > > > > From: Thomas Monjalon [mailto:thomas@monjalon.net]
> > > > > > > 13/11/2018 17:38, Burdick, Cliff:
> > > > > > > > From: Thomas Monjalon [mailto:thomas@monjalon.net]
> > > > > > > > 13/11/2018 16:45, Burdick, Cliff:
> > > > > > > > > From: Burakov, Anatoly [mailto:anatoly.burakov@intel.
> > > > > > > > > com]
> > > > > > > > > > On 13-Nov-18 9:21 AM, Thomas Monjalon wrote:
> > > > > > > > > > > 13/11/2018 00:33, Burdick, Cliff:
> > > > > > > > > > > > This patch was submitted by Jean Tourrilhes
> > > > > > > > > > > > over two 
> > > > > > > > > > > > years ago, but didn't receive any responses. I
> > > > > > > > > > > > hit 
> > > > > > > > > > > > the same issue recently when trying to use cgo 
> > > > > > > > > > > > (Golang) as a primary process linked to
> > > > > > > > > > > > libdpdk.a 
> > > > > > > > > > > > against a C++ application linked against the
> > > > > > > > > > > > same 
> > > > > > > > > > > > library.> > >
> > > > > > > > > > > 
> > > > > > > > > > > The question is to know why you don't have the
> > > > > > > > > > > same 
> > > > > > > > > > > constructors in primary and seconday?
> > > > > > > > > > 
> > > > > > > > > > I've hit similar things in the past. I believe it
> > > > > > > > > > was 
> > > > > > > > > > caused by our build system stripping out unused 
> > > > > > > > > > libraries (such as
> > > > > > > > > > rte_hash) from the binary and thus not calling the 
> > > > > > > > > > constructor in the primary, but doing so in the 
> > > > > > > > > > secondary (or something to that effect). In any
> > > > > > > > > > case, 
> > > > > > > > > > this is caused by linking different number of
> > > > > > > > > > libraries 
> > > > > > > > > > to primary and secondary, and should probably be
> > > > > > > > > > fixed 
> > > > > > > > > > in the build system, not in the tailqs code (unless
> > > > > > > > > > we 
> > > > > > > > > > specifically support having different linked
> > > > > > > > > > libraries 
> > > > > > > > > > to primary and secondary?).> > > >
> > > > > > > > > 
> > > > > > > > > Right, I think the original author of the patch
> > > > > > > > > stated the 
> > > > > > > > > reasons in the link I provided. The build system
> > > > > > > > > seems 
> > > > > > > > > like the most appropriate place to fix it, but the
> > > > > > > > > patch 
> > > > > > > > > got me going quickly. I think the question is whether
> > > > > > > > > you 
> > > > > > > > > want DPDK to support these other ways of linking.
> > > > > > > > > I'm 
> > > > > > > > > certainly not the first to use cgo, since there's a 
> > > > > > > > > virtual switch project doing the same:
> > > > > > > > > 
> > > > > > > > > https://urldefense.proofpoint.com/v2/url?u=https-3A__
> > > > > > > > > gith
> > > > > > > > > ub.co
> > > > > > > > > m_lago
> > > > > > > > > pu
> > > > > > > > > s_vsw&d=DwICAg&c=jcv3orpCsv7C4ly8-
> > > > > > > > > ubDoUfrxF5xIGWmptxGWP5vi5w&r =m1RLQ OG
> > > > > > > > > Okz9MauvVLZmiGtyWc5mA7DejbPFNE1IDj-
> > > > > > > > > 4&m=hQqVCNwW7eoEzB_hLFK97i8 idS8FI qX
> > > > > > > > > oPeclwsIZq7Y&s=BMoBlwkqljwWIBY3SE3pPMCfVnOUlDuZLrno4-
> > > > > > > > > SojKM&e=
> > > > > > > > > 
> > > > > > > > > They don't use primary/secondary processes, though,
> > > > > > > > > so the 
> > > > > > > > > issue is  never hit. I'm in a situation where using
> > > > > > > > > cgo 
> > > > > > > > > seemed like the easiest  path to accomplish what I'm
> > > > > > > > > doing 
> > > > > > > > > since I needed specialized  libraries for it that
> > > > > > > > > were not 
> > > > > > > > > available in C/C++. At some point I  bet someone
> > > > > > > > > would use 
> > > > > > > > > Cython to start linking against DPDK as well,  and
> > > > > > > > > we'd 
> > > > > > > > > likely run into the same issue.> > > > For sure, we
> > > > > > > > > want 
> > > > > > > > > to support using DPDK with cgo or cython.
> > > > > > > > > But it is not clear what is the relation with not
> > > > > > > > > having 
> > > > > > > > > the same compilation for primary and secondary.
> > > > > > > > > Please 
> > > > > > > > > could you elaborate?> > >
> > > > > > > > 
> > > > > > > > Hi Thomas, I think Jean explained it well here:
> > > > > > > > https://urldefense.proofpoint.com/v2/url?u=https-3A__de
> > > > > > > > v.dp
> > > > > > > > dk.narkive.
> > > > > > > > com_ZM3a7QD1_dpdk-2Ddev-2Dbug-2Dstatic-2Dconstructors-
> > > > > > > > 2Dconsider
> > > > > > > > ed-2De
> > > > > > > > vil&d=DwICAg&c=jcv3orpCsv7C4ly8- 
> > > > > > > > ubDoUfrxF5xIGWmptxGWP5vi5w&r=m1R LQOGOk
> > > > > > > > z9MauvVLZmiGtyWc5mA7DejbPFNE1IDj- 
> > > > > > > > 4&m=C69wDgrjDX8_oXp1M_3bnmWOOZd GqwBBG 
> > > > > > > > 9vzkyGDWGQ&s=YYn2N7WrzJpH1ptNrLZad0nPAQdrUyqBckk2uFuWYP
> > > > > > > > Q&e=
> > > > > > > > 
> > > > > > > > "The build system of the application does not have all
> > > > > > > > the 
> > > > > > > > subtelties of the DPDK build system, and ends up
> > > > > > > > including
> > > > > > > > *all*
> > > > > > > > the constructors, wether they are used or not in the
> > > > > > > > code. 
> > > > > > > > Moreover, they are included in a different order.
> > > > > > > > Actually, 
> > > > > > > > by default the builds include no constructors at all
> > > > > > > > (which 
> > > > > > > > is a big fail), so the library needs to be included
> > > > > > > > with 
> > > > > > > > --whole-archive (see Snort DPDK instructions)."
> > > > > > > > 
> > > > > > > > I will get to the bottom of my exact case to
> > > > > > > > understand 
> > > > > > > > what's happening, but my primary application is a cgo 
> > > > > > > > application that I'm linking to by using almost exactly
> > > > > > > > the 
> > > > > > > > same flags that are used in the DPDK build system to
> > > > > > > > build 
> > > > > > > > examples. The DPDK libraries I'm linking against is a
> > > > > > > > single 
> > > > > > > > location for both primary and secondary; in other
> > > > > > > > words, I 
> > > > > > > > don't build DPDK twice.
> > > > > > > > 
> > > > > > > > OK I understand, thanks.
> > > > > > > > 
> > > > > > > > You had alluded to a pkg-config for DPDK in the 2015
> > > > > > > > thread, 
> > > > > > > > which cgo can use, but I don't know if that ever was 
> > > > > > > > implemented. Cgo can use pkg-config if it's available, 
> > > > > > > > otherwise the only tools are specifying LDFLAGS and
> > > > > > > > CFLAGS 
> > > > > > > > into their build system.
> > > > > > > 
> > > > > > > Yes, the right answer is still pkg-config :) The good
> > > > > > > news is 
> > > > > > > that it is now implemented thanks to the meson build
> > > > > > > system:
> > > > > > >     
> > > > > > > https://urldefense.proofpoint.com/v2/url?u=http-3A__git.d
> > > > > > > pdk.
> > > > > > > org_dp
> > > > > > > dk_tree_doc_build-2Dsdk-2Dmeson.txt-
> > > > > > > 23n182&d=DwICAg&c=jcv3orpCsv7C4
> > > > > > > ly8-
> > > > > > > ubDoUfrxF5xIGWmptxGWP5vi5w&r=m1RLQOGOkz9MauvVLZmiGtyWc5mA
> > > > > > > 7Dej
> > > > > > > bP
> > > > > > > FNE1IDj-
> > > > > > > > 4&m=C69wDgrjDX8_oXp1M_3bnmWOOZdGqwBBG9vzkyGDWGQ&s=oC86K
> > > > > > > > D_R
> > > > > > > 
> > > > > > > J1T6rfzi3x5zFT1Ri13ELpKmsyFqpgDbgFg&e=
> > > > > > 
> > > > > > Hi Thomas, are there instructions on how to use pkg-config
> > > > > > to 
> > > > > > build the mlx4/5 PMD? I noticed a patch was submitted in 
> > > > > > September to add support for it, but that link you provided
> > > > > > on 
> > > > > > using meson doesn't say how to build specific drivers. It 
> > > > > > appears to be disabled by default.
> > > > > > If the dependency is found, meson will enable the PMD when 
> > > > > > building DPDK.
> > > > > 
> > > > > Do you know where exactly that is? I've been using mlx5 for
> > > > > a 
> > > > > while on this system, and I can see that 18.11-rc2 meson
> > > > > build+ninja built the pmd, but it's not on the --libs listing
> > > > > for
> > > > > pkg-config. Does it tell me what I was missing?
> > > > > 
> > > > 
> > > > For dynamic linking of applications, the drivers are not
> > > > normally 
> > > > linked in. Instead, they should be loaded from the drivers
> > > > directory 
> > > > as .so files
> > > > - normally by default in EAL as the driver .so's should be
> > > > copied to 
> > > > the EAL_PMD_PATH where EAL finds them automatically. [This
> > > > applies 
> > > > to both meson and make builds, though only meson generates the
> > > > .pc 
> > > > file for pkg-config]
> > > > 
> > > > If you are doing a static build, then you need to explicitly
> > > > link in 
> > > > the drivers. You can get a list from pkg-config using the "
> > > > --static" flag in this case. A good example of how to use pkg- 
> > > > config in this way can be found in the Makefiles for most
> > > > examples, 
> > > > e.g. examples/helloworld/Makefile, reproduced below.
> > > > 
> > > > Regards,
> > > > /Bruce
> > > > 
> > > > all: shared
> > > > .PHONY: shared static
> > > > shared: build/$(APP)-shared
> > > >         ln -sf $(APP)-shared build/$(APP)
> > > > static: build/$(APP)-static
> > > >         ln -sf $(APP)-static build/$(APP)
> > > > 
> > > > PC_FILE := $(shell pkg-config --path libdpdk) CFLAGS += -O3
> > > > $(shell 
> > > > pkg-config --cflags libdpdk) LDFLAGS_SHARED = $(shell pkg-
> > > > config -- 
> > > > libs libdpdk) LDFLAGS_STATIC = -Wl,-Bstatic $(shell pkg-config
> > > > -- 
> > > > static --libs libdpdk)
> > > > 
> > > > build/$(APP)-shared: $(SRCS-y) Makefile $(PC_FILE) | build
> > > >         $(CC) $(CFLAGS) $(SRCS-y) -o $@ $(LDFLAGS)
> > > > $(LDFLAGS_SHARED)
> > > > 
> > > > build/$(APP)-static: $(SRCS-y) Makefile $(PC_FILE) | build
> > > >         $(CC) $(CFLAGS) $(SRCS-y) -o $@ $(LDFLAGS)
> > > > $(LDFLAGS_STATIC)
> > > > 
> > > > build:
> > > >         @mkdir -p $@
> > > 
> > > Thanks Bruce. I tried getting this to compile using cgo, and
> > > it's 
> > > causing more pain than it's worth. I used the --static --libs
> > > options, 
> > > and there were still numerous linker errors, some specific to
> > > mlx, and 
> > > some not. Specifically libmlx5 and libmnl are both needed, but
> > > they're 
> > > not part of the linker line from pkg-config. At this point I'll
> > > just 
> > > break the Go application up into a separate C application that
> > > handles 
> > > all the DPDK parts, and send messages between them.
> > 
> > Hi,
> > 
> > As far as I can see, both mnl and mlx5 (and all the other reverse
> > dependencies) are listed correctly in the libdpdk.pc Libs.private
> > entry, and pkg-config --libs --static libdpdk.pc does print them as
> > intended. This is with 18.11-rc3.
> > Are you sure everything is correct (pkg-config path is right, --
> > static is used, etc)?
> > 
> > --
> > Kind regards,
> > Luca Boccassi
> 
> Hi Luca, here is what pkg-config gives:
> 
> PKG_CONFIG_PATH=meson-private/ pkg-config --libs --static libdpdk
> -L/usr/local/lib/x86_64-linux-gnu -lrte_eventdev -lrte_power
> -lrte_ip_frag -lrte_hash -lrte_pdump -lrte_eal -lrte_pipeline
> -lrte_table -lrte_bbdev -lrte_bpf -lrte_vhost -lrte_metrics
> -lrte_jobstats -lrte_net -lrte_reorder -lrte_ring -lrte_mempool
> -lrte_security -lrte_compressdev -lrte_rawdev -lrte_mbuf -lrte_kvargs
> -lrte_port -lrte_pci -lrte_ethdev -lrte_gro -lrte_gso -lrte_cryptodev
> -lrte_sched -lrte_latencystats -lrte_efd -lrte_distributor
> -lrte_meter -lrte_acl -lrte_member -lrte_cmdline -lrte_lpm -lrte_kni
> -lrte_cfgfile -lrte_bitratestats -lrte_timer -lrte_flow_classify
> -lrte_mempool_bucket -lrte_pmd_null_crypto -lrte_pmd_failsafe
> -lrte_bus_ifpga -lrte_pmd_atlantic -lrte_pmd_mlx4 -lrte_pmd_vmxnet3
> -lrte_pmd_avp -lrte_common_dpaax -lrte_pmd_ena -lcrypto
> -lrte_bus_fslmc -ldl -lrte_pmd_avf -lrte_pmd_crypto_scheduler
> -lrte_pmd_netvsc -lrte_pmd_vhost -lrte_bus_dpaa -lrte_mempool_dpaa2
> -lrte_common_octeontx -lrte_pmd_liquidio -lrte_pmd_ifc -Wl,-Bdynamic
> -lnuma -lrte_pmd_enic -lrte_common_cpt -pthread
> -lrte_pmd_octeontx_crypto -lrte_pmd_qat -lrte_bus_vmbus
> -lrte_pmd_null -lm -lrte_pmd_dpaa -lrte_bus_vdev -lrte_pmd_dpaa2
> -lrte_pmd_skeleton_event -lrte_pmd_af_packet -lrte_pmd_octeontx
> -lrte_pmd_thunderx -lrte_pmd_ring -lrte_pmd_octeontx_event
> -lrte_pmd_sw_event -lrte_pmd_ark -lrte_mempool_octeontx
> -lrte_pmd_ixgbe -lrte_pmd_kni -lrte_mempool_ring
> -lrte_pmd_virtio_crypto -lrte_mempool_dpaa -lrte_pmd_dpaa2_cmdif
> -lrte_bus_pci -lrte_pmd_opdl_event -lrte_pmd_mlx5 -lrte_pmd_virtio
> -lrte_pmd_tap -lrte_pmd_caam_jr -lrte_pmd_dpaa2_sec
> -lrte_pmd_dpaa2_qdma -lrte_pmd_enetc -lrte_pmd_sfc -lrte_pmd_bnxt
> -lrte_pmd_dpaa2_event -lrte_pmd_cxgbe -Wl,--whole-archive -Wl,--no-
> as-needed -lrte_pmd_e1000 -lrte_pmd_softnic -lrte_pmd_bond
> -lrte_pmd_fm10k -lrte_pmd_i40e -lrte_pmd_nfp -lrte_pmd_qede -Wl,--no-
> whole-archive -lrte_pmd_axgbe -lrte_pmd_ccp -lrte_pmd_ifpga_rawdev
> -lrte_pmd_bbdev_null -lrte_pmd_openssl -lrte_pmd_dsw_event
> -lrte_pmd_dpaa_event -lrte_mempool_stack -lrte_pmd_vdev_netvsc
> -lrte_pmd_dpaa_sec -lrte_pmd_skeleton_rawdev
> -lrte_pmd_octeontx_compress
> 
> You'll notice there's no mlx5 or mnl in that list. I was using 18.11-
> rc2 since I cloned early yesterday. Perhaps meson determined not to
> put it in there for some reason?

Were mlx5/mnl found at meson configure time?

-- 
Kind regards,
Luca Boccassi

Re: [dpdk-dev] [PATCH 1/1] eal: Don't fail secondary if primary is missing tailqs

[Burdick, Cliff]

-----Original Message-----
From: Luca Boccassi [mailto:bluca@debian.org] 
Sent: Thursday, November 15, 2018 1:33 AM
To: Burdick, Cliff; Bruce Richardson
Cc: Thomas Monjalon; Burakov, Anatoly; dev@dpdk.org
Subject: Re: [dpdk-dev] [PATCH 1/1] eal: Don't fail secondary if primary is missing tailqs

> On Wed, 2018-11-14 at 18:24 +0000, Burdick, Cliff wrote:
> > 
> > -----Original Message-----
> > From: Luca Boccassi [mailto:bluca@debian.org]
> > Sent: Wednesday, November 14, 2018 10:15 AM
> > To: Burdick, Cliff; Bruce Richardson
> > Cc: Thomas Monjalon; Burakov, Anatoly; dev@dpdk.org
> > Subject: Re: [dpdk-dev] [PATCH 1/1] eal: Don't fail secondary if 
> > primary is missing tailqs
> > 
> > > On Wed, 2018-11-14 at 17:40 +0000, Burdick, Cliff wrote:
> > > > 
> > > > -----Original Message-----
> > > > From: Bruce Richardson [mailto:bruce.richardson@intel.com]
> > > > Sent: Wednesday, November 14, 2018 3:48 AM
> > > > To: Burdick, Cliff
> > > > Cc: Thomas Monjalon; Burakov, Anatoly; dev@dpdk.org
> > > > Subject: Re: [dpdk-dev] [PATCH 1/1] eal: Don't fail secondary if 
> > > > primary is missing tailqs
> > > > 
> > > > On Tue, Nov 13, 2018 at 11:42:51PM +0000, Burdick, Cliff wrote:
> > > > > > 
> > > > > > ________________________________________
> > > > > > From: Thomas Monjalon [thomas@monjalon.net]
> > > > > > Sent: Tuesday, November 13, 2018 2:18 PM
> > > > > > To: Burdick, Cliff
> > > > > > Cc: Burakov, Anatoly; dev@dpdk.org; bruce.richardson@intel.co 
> > > > > > m
> > > > > > Subject: Re: [dpdk-dev] [PATCH 1/1] eal: Don't fail secondary 
> > > > > > if primary is missing tailqs
> > > > > > 
> > > > > > 13/11/2018 23:08, Burdick, Cliff:
> > > > > > > From: Thomas Monjalon [mailto:thomas@monjalon.net]
> > > > > > > > 13/11/2018 17:38, Burdick, Cliff:
> > > > > > > > > From: Thomas Monjalon [mailto:thomas@monjalon.net]
> > > > > > > > > 13/11/2018 16:45, Burdick, Cliff:
> > > > > > > > > > From: Burakov, Anatoly [mailto:anatoly.burakov@intel.
> > > > > > > > > > com]
> > > > > > > > > > > On 13-Nov-18 9:21 AM, Thomas Monjalon wrote:
> > > > > > > > > > > > 13/11/2018 00:33, Burdick, Cliff:
> > > > > > > > > > > > > This patch was submitted by Jean Tourrilhes over 
> > > > > > > > > > > > > two years ago, but didn't receive any responses. 
> > > > > > > > > > > > > I hit the same issue recently when trying to use 
> > > > > > > > > > > > > cgo
> > > > > > > > > > > > > (Golang) as a primary process linked to 
> > > > > > > > > > > > > libdpdk.a against a C++ application linked 
> > > > > > > > > > > > > against the same library.> > >
> > > > > > > > > > > > 
> > > > > > > > > > > > The question is to know why you don't have the 
> > > > > > > > > > > > same constructors in primary and seconday?
> > > > > > > > > > > 
> > > > > > > > > > > I've hit similar things in the past. I believe it 
> > > > > > > > > > > was caused by our build system stripping out unused 
> > > > > > > > > > > libraries (such as
> > > > > > > > > > > rte_hash) from the binary and thus not calling the 
> > > > > > > > > > > constructor in the primary, but doing so in the 
> > > > > > > > > > > secondary (or something to that effect). In any 
> > > > > > > > > > > case, this is caused by linking different number of 
> > > > > > > > > > > libraries to primary and secondary, and should 
> > > > > > > > > > > probably be fixed in the build system, not in the 
> > > > > > > > > > > tailqs code (unless we specifically support having 
> > > > > > > > > > > different linked libraries to primary and 
> > > > > > > > > > > secondary?).> > > >
> > > > > > > > > > 
> > > > > > > > > > Right, I think the original author of the patch stated 
> > > > > > > > > > the reasons in the link I provided. The build system 
> > > > > > > > > > seems like the most appropriate place to fix it, but 
> > > > > > > > > > the patch got me going quickly. I think the question 
> > > > > > > > > > is whether you want DPDK to support these other ways 
> > > > > > > > > > of linking.
> > > > > > > > > > I'm
> > > > > > > > > > certainly not the first to use cgo, since there's a 
> > > > > > > > > > virtual switch project doing the same:
> > > > > > > > > > 
> > > > > > > > > > https://urldefense.proofpoint.com/v2/url?u=https-3A__
> > > > > > > > > > gith
> > > > > > > > > > ub.co
> > > > > > > > > > m_lago
> > > > > > > > > > pu
> > > > > > > > > > s_vsw&d=DwICAg&c=jcv3orpCsv7C4ly8-
> > > > > > > > > > ubDoUfrxF5xIGWmptxGWP5vi5w&r =m1RLQ OG
> > > > > > > > > > Okz9MauvVLZmiGtyWc5mA7DejbPFNE1IDj-
> > > > > > > > > > 4&m=hQqVCNwW7eoEzB_hLFK97i8 idS8FI qX
> > > > > > > > > > oPeclwsIZq7Y&s=BMoBlwkqljwWIBY3SE3pPMCfVnOUlDuZLrno4-
> > > > > > > > > > SojKM&e=
> > > > > > > > > > 
> > > > > > > > > > They don't use primary/secondary processes, though, so 
> > > > > > > > > > the issue is  never hit. I'm in a situation where 
> > > > > > > > > > using cgo seemed like the easiest  path to accomplish 
> > > > > > > > > > what I'm doing since I needed specialized  libraries 
> > > > > > > > > > for it that were not available in C/C++. At some point 
> > > > > > > > > > I  bet someone would use Cython to start linking 
> > > > > > > > > > against DPDK as well,  and we'd likely run into the 
> > > > > > > > > > same issue.> > > > For sure, we want to support using 
> > > > > > > > > > DPDK with cgo or cython.
> > > > > > > > > > But it is not clear what is the relation with not 
> > > > > > > > > > having the same compilation for primary and secondary.
> > > > > > > > > > Please
> > > > > > > > > > could you elaborate?> > >
> > > > > > > > > 
> > > > > > > > > Hi Thomas, I think Jean explained it well here:
> > > > > > > > > https://urldefense.proofpoint.com/v2/url?u=https-3A__de
> > > > > > > > > v.dp
> > > > > > > > > dk.narkive.
> > > > > > > > > com_ZM3a7QD1_dpdk-2Ddev-2Dbug-2Dstatic-2Dconstructors-
> > > > > > > > > 2Dconsider
> > > > > > > > > ed-2De
> > > > > > > > > vil&d=DwICAg&c=jcv3orpCsv7C4ly8- 
> > > > > > > > > ubDoUfrxF5xIGWmptxGWP5vi5w&r=m1R LQOGOk
> > > > > > > > > z9MauvVLZmiGtyWc5mA7DejbPFNE1IDj- 
> > > > > > > > > 4&m=C69wDgrjDX8_oXp1M_3bnmWOOZd GqwBBG 
> > > > > > > > > 9vzkyGDWGQ&s=YYn2N7WrzJpH1ptNrLZad0nPAQdrUyqBckk2uFuWYP
> > > > > > > > > Q&e=
> > > > > > > > > 
> > > > > > > > > "The build system of the application does not have all 
> > > > > > > > > the subtelties of the DPDK build system, and ends up 
> > > > > > > > > including
> > > > > > > > > *all*
> > > > > > > > > the constructors, wether they are used or not in the 
> > > > > > > > > code.
> > > > > > > > > Moreover, they are included in a different order.
> > > > > > > > > Actually,
> > > > > > > > > by default the builds include no constructors at all 
> > > > > > > > > (which is a big fail), so the library needs to be 
> > > > > > > > > included with --whole-archive (see Snort DPDK 
> > > > > > > > > instructions)."
> > > > > > > > > 
> > > > > > > > > I will get to the bottom of my exact case to understand 
> > > > > > > > > what's happening, but my primary application is a cgo 
> > > > > > > > > application that I'm linking to by using almost exactly 
> > > > > > > > > the same flags that are used in the DPDK build system to 
> > > > > > > > > build examples. The DPDK libraries I'm linking against 
> > > > > > > > > is a single location for both primary and secondary; in 
> > > > > > > > > other words, I don't build DPDK twice.
> > > > > > > > > 
> > > > > > > > > OK I understand, thanks.
> > > > > > > > > 
> > > > > > > > > You had alluded to a pkg-config for DPDK in the 2015 
> > > > > > > > > thread, which cgo can use, but I don't know if that ever 
> > > > > > > > > was implemented. Cgo can use pkg-config if it's 
> > > > > > > > > available, otherwise the only tools are specifying 
> > > > > > > > > LDFLAGS and CFLAGS into their build system.
> > > > > > > > 
> > > > > > > > Yes, the right answer is still pkg-config :) The good news 
> > > > > > > > is that it is now implemented thanks to the meson build
> > > > > > > > system:
> > > > > > > >     
> > > > > > > > https://urldefense.proofpoint.com/v2/url?u=http-3A__git.d
> > > > > > > > pdk.
> > > > > > > > org_dp
> > > > > > > > dk_tree_doc_build-2Dsdk-2Dmeson.txt-
> > > > > > > > 23n182&d=DwICAg&c=jcv3orpCsv7C4
> > > > > > > > ly8-
> > > > > > > > ubDoUfrxF5xIGWmptxGWP5vi5w&r=m1RLQOGOkz9MauvVLZmiGtyWc5mA
> > > > > > > > 7Dej
> > > > > > > > bP
> > > > > > > > FNE1IDj-
> > > > > > > > > 4&m=C69wDgrjDX8_oXp1M_3bnmWOOZdGqwBBG9vzkyGDWGQ&s=oC86K
> > > > > > > > > D_R
> > > > > > > > 
> > > > > > > > J1T6rfzi3x5zFT1Ri13ELpKmsyFqpgDbgFg&e=
> > > > > > > 
> > > > > > > Hi Thomas, are there instructions on how to use pkg-config 
> > > > > > > to build the mlx4/5 PMD? I noticed a patch was submitted in 
> > > > > > > September to add support for it, but that link you provided 
> > > > > > > on using meson doesn't say how to build specific drivers. It 
> > > > > > > appears to be disabled by default.
> > > > > > > If the dependency is found, meson will enable the PMD when 
> > > > > > > building DPDK.
> > > > > > 
> > > > > > Do you know where exactly that is? I've been using mlx5 for a 
> > > > > > while on this system, and I can see that 18.11-rc2 meson
> > > > > > build+ninja built the pmd, but it's not on the --libs listing
> > > > > > for
> > > > > > pkg-config. Does it tell me what I was missing?
> > > > > > 
> > > > > 
> > > > > For dynamic linking of applications, the drivers are not 
> > > > > normally linked in. Instead, they should be loaded from the 
> > > > > drivers directory as .so files
> > > > > - normally by default in EAL as the driver .so's should be 
> > > > > copied to the EAL_PMD_PATH where EAL finds them automatically. 
> > > > > [This applies to both meson and make builds, though only meson 
> > > > > generates the .pc file for pkg-config]
> > > > > 
> > > > > If you are doing a static build, then you need to explicitly 
> > > > > link in the drivers. You can get a list from pkg-config using 
> > > > > the "
> > > > > --static" flag in this case. A good example of how to use pkg- 
> > > > > config in this way can be found in the Makefiles for most 
> > > > > examples, e.g. examples/helloworld/Makefile, reproduced below.
> > > > > 
> > > > > Regards,
> > > > > /Bruce
> > > > > 
> > > > > all: shared
> > > > > .PHONY: shared static
> > > > > shared: build/$(APP)-shared
> > > > >         ln -sf $(APP)-shared build/$(APP)
> > > > > static: build/$(APP)-static
> > > > >         ln -sf $(APP)-static build/$(APP)
> > > > > 
> > > > > PC_FILE := $(shell pkg-config --path libdpdk) CFLAGS += -O3 
> > > > > $(shell pkg-config --cflags libdpdk) LDFLAGS_SHARED = $(shell 
> > > > > pkg- config -- libs libdpdk) LDFLAGS_STATIC = -Wl,-Bstatic 
> > > > > $(shell pkg-config
> > > > > --
> > > > > static --libs libdpdk)
> > > > > 
> > > > > build/$(APP)-shared: $(SRCS-y) Makefile $(PC_FILE) | build
> > > > >         $(CC) $(CFLAGS) $(SRCS-y) -o $@ $(LDFLAGS)
> > > > > $(LDFLAGS_SHARED)
> > > > > 
> > > > > build/$(APP)-static: $(SRCS-y) Makefile $(PC_FILE) | build
> > > > >         $(CC) $(CFLAGS) $(SRCS-y) -o $@ $(LDFLAGS)
> > > > > $(LDFLAGS_STATIC)
> > > > > 
> > > > > build:
> > > > >         @mkdir -p $@
> > > > 
> > > > Thanks Bruce. I tried getting this to compile using cgo, and it's 
> > > > causing more pain than it's worth. I used the --static --libs 
> > > > options, and there were still numerous linker errors, some 
> > > > specific to mlx, and some not. Specifically libmlx5 and libmnl are 
> > > > both needed, but they're not part of the linker line from 
> > > > pkg-config. At this point I'll just break the Go application up 
> > > > into a separate C application that handles all the DPDK parts, and 
> > > > send messages between them.
> > > 
> > > Hi,
> > > 
> > > As far as I can see, both mnl and mlx5 (and all the other reverse
> > > dependencies) are listed correctly in the libdpdk.pc Libs.private 
> > > entry, and pkg-config --libs --static libdpdk.pc does print them as 
> > > intended. This is with 18.11-rc3.
> > > Are you sure everything is correct (pkg-config path is right, -- 
> > > static is used, etc)?
> > > 
> > > --
> > > Kind regards,
> > > Luca Boccassi
> > 
> > Hi Luca, here is what pkg-config gives:
> > 
> > PKG_CONFIG_PATH=meson-private/ pkg-config --libs --static libdpdk 
> > -L/usr/local/lib/x86_64-linux-gnu -lrte_eventdev -lrte_power 
> > -lrte_ip_frag -lrte_hash -lrte_pdump -lrte_eal -lrte_pipeline 
> > -lrte_table -lrte_bbdev -lrte_bpf -lrte_vhost -lrte_metrics 
> > -lrte_jobstats -lrte_net -lrte_reorder -lrte_ring -lrte_mempool 
> > -lrte_security -lrte_compressdev -lrte_rawdev -lrte_mbuf -lrte_kvargs 
> > -lrte_port -lrte_pci -lrte_ethdev -lrte_gro -lrte_gso -lrte_cryptodev 
> > -lrte_sched -lrte_latencystats -lrte_efd -lrte_distributor -lrte_meter 
> > -lrte_acl -lrte_member -lrte_cmdline -lrte_lpm -lrte_kni -lrte_cfgfile 
> > -lrte_bitratestats -lrte_timer -lrte_flow_classify 
> > -lrte_mempool_bucket -lrte_pmd_null_crypto -lrte_pmd_failsafe 
> > -lrte_bus_ifpga -lrte_pmd_atlantic -lrte_pmd_mlx4 -lrte_pmd_vmxnet3 
> > -lrte_pmd_avp -lrte_common_dpaax -lrte_pmd_ena -lcrypto 
> > -lrte_bus_fslmc -ldl -lrte_pmd_avf -lrte_pmd_crypto_scheduler 
> > -lrte_pmd_netvsc -lrte_pmd_vhost -lrte_bus_dpaa -lrte_mempool_dpaa2 
> > -lrte_common_octeontx -lrte_pmd_liquidio -lrte_pmd_ifc -Wl,-Bdynamic 
> > -lnuma -lrte_pmd_enic -lrte_common_cpt -pthread 
> > -lrte_pmd_octeontx_crypto -lrte_pmd_qat -lrte_bus_vmbus -lrte_pmd_null 
> > -lm -lrte_pmd_dpaa -lrte_bus_vdev -lrte_pmd_dpaa2 
> > -lrte_pmd_skeleton_event -lrte_pmd_af_packet -lrte_pmd_octeontx 
> > -lrte_pmd_thunderx -lrte_pmd_ring -lrte_pmd_octeontx_event 
> > -lrte_pmd_sw_event -lrte_pmd_ark -lrte_mempool_octeontx 
> > -lrte_pmd_ixgbe -lrte_pmd_kni -lrte_mempool_ring 
> > -lrte_pmd_virtio_crypto -lrte_mempool_dpaa -lrte_pmd_dpaa2_cmdif 
> > -lrte_bus_pci -lrte_pmd_opdl_event -lrte_pmd_mlx5 -lrte_pmd_virtio 
> > -lrte_pmd_tap -lrte_pmd_caam_jr -lrte_pmd_dpaa2_sec 
> > -lrte_pmd_dpaa2_qdma -lrte_pmd_enetc -lrte_pmd_sfc -lrte_pmd_bnxt 
> > -lrte_pmd_dpaa2_event -lrte_pmd_cxgbe -Wl,--whole-archive -Wl,--no- 
> > as-needed -lrte_pmd_e1000 -lrte_pmd_softnic -lrte_pmd_bond 
> > -lrte_pmd_fm10k -lrte_pmd_i40e -lrte_pmd_nfp -lrte_pmd_qede -Wl,--no- 
> > whole-archive -lrte_pmd_axgbe -lrte_pmd_ccp -lrte_pmd_ifpga_rawdev 
> > -lrte_pmd_bbdev_null -lrte_pmd_openssl -lrte_pmd_dsw_event 
> > -lrte_pmd_dpaa_event -lrte_mempool_stack -lrte_pmd_vdev_netvsc 
> > -lrte_pmd_dpaa_sec -lrte_pmd_skeleton_rawdev 
> > -lrte_pmd_octeontx_compress
> > 
> > You'll notice there's no mlx5 or mnl in that list. I was using 18.11-
> > rc2 since I cloned early yesterday. Perhaps meson determined not to 
> > put it in there for some reason?
> 
> Were mlx5/mnl found at meson configure time?
> 
> --
> Kind regards,
> Luca Boccassi

Hi Luca, yes, it was:

Library mnl found: YES
Library mlx4 found: YES
Library ibverbs found: YES
Compiler for C supports argument -Wextra: YES
Compiler for C supports argument -std=c11: YES
Compiler for C supports argument -Wno-strict-prototypes: YES
Compiler for C supports argument -D_BSD_SOURCE: YES
Compiler for C supports argument -D_DEFAULT_SOURCE: YES
Compiler for C supports argument -D_XOPEN_SOURCE=600: YES
Checking whether type "struct mlx4_wqe_lso_seg" has member "mss_hdr_size": YES
Configuring mlx4_autoconf.h using configuration
Library mnl found: YES
Library mlx5 found: YES
Library ibverbs found: YES
...
PKG_CONFIG_PATH=meson-private/ pkg-config --libs --static libdpdk
-L/usr/local/lib/x86_64-linux-gnu -lrte_eventdev -lrte_power -lrte_ip_frag -lrte_hash -lrte_pdump -lrte_eal -lrte_pipeline -lrte_table -lrte_bbdev -lrte_bpf -lrte_vhost -lrte_metrics -lrte_jobstats -lrte_net -lrte_reorder -lrte_ring -lrte_mempool -lrte_security -lrte_compressdev -lrte_rawdev -lrte_mbuf -lrte_kvargs -lrte_port -lrte_pci -lrte_ethdev -lrte_gro -lrte_gso -lrte_cryptodev -lrte_sched -lrte_latencystats -lrte_efd -lrte_distributor -lrte_meter -lrte_acl -lrte_member -lrte_cmdline -lrte_lpm -lrte_kni -lrte_cfgfile -lrte_bitratestats -lrte_timer -lrte_flow_classify -lrte_pmd_ccp -lrte_mempool_bucket -lrte_pmd_failsafe -lrte_pmd_netvsc -lrte_pmd_null_crypto -lrte_bus_ifpga -lrte_pmd_atlantic -lrte_pmd_octeontx_event -lrte_pmd_avp -lrte_pmd_mlx4 -lrte_common_dpaax -lrte_pmd_skeleton_rawdev -lrte_pmd_ena -lrte_pmd_opdl_event -lrte_bus_fslmc -lnuma -lrte_pmd_avf -lrte_pmd_crypto_scheduler -lrte_pmd_vhost -lrte_bus_dpaa -lrte_mempool_dpaa2 -lrte_common_octeontx -Wl,--no-as-needed -lcrypto -lrte_pmd_ifc -lrte_pmd_liquidio -lrte_pmd_enic -lrte_common_cpt -Wl,--no-whole-archive -lrte_bus_vmbus -lrte_pmd_octeontx_crypto -lrte_pmd_qat -lrte_pmd_ifpga_rawdev -lrte_pmd_dpaa -lrte_bus_vdev -lrte_pmd_bbdev_null -lrte_pmd_dpaa2 -lrte_pmd_skeleton_event -lrte_pmd_ring -lrte_pmd_af_packet -lrte_pmd_thunderx -lrte_pmd_dpaa_event -lrte_pmd_octeontx_compress -lrte_pmd_dpaa_sec -lrte_pmd_sw_event -Wl,--whole-archive -lrte_pmd_ark -lrte_mempool_octeontx -lrte_pmd_ixgbe -lrte_mempool_ring -lrte_pmd_kni -lrte_pmd_vmxnet3 -lrte_mempool_dpaa -lrte_bus_pci -lrte_pmd_dpaa2_cmdif -lrte_pmd_mlx5 -lrte_pmd_tap -lrte_pmd_caam_jr -lrte_pmd_dpaa2_sec -lm -lrte_pmd_dpaa2_qdma -lrte_pmd_enetc -lrte_pmd_virtio -lrte_pmd_bnxt -lrte_pmd_dpaa2_event -lrte_pmd_sfc -lrte_pmd_cxgbe -pthread -lrte_pmd_e1000 -lrte_pmd_softnic -ldl -lrte_pmd_null -lrte_pmd_bond -lrte_pmd_fm10k -lrte_pmd_i40e -lrte_pmd_nfp -lrte_pmd_qede -lrte_pmd_axgbe -Wl,-Bdynamic -lrte_pmd_openssl -lrte_pmd_octeontx -lrte_pmd_dsw_event -lrte_mempool_stack -lrte_pmd_virtio_crypto -lrte_pmd_vdev_netvsc

Re: [dpdk-dev] [PATCH 1/1] eal: Don't fail secondary if primary is missing tailqs

[Bruce Richardson]

On Thu, Nov 15, 2018 at 04:15:36PM +0000, Burdick, Cliff wrote:
> 
> 
> -----Original Message-----
> From: Luca Boccassi [mailto:bluca@debian.org] 
> Sent: Thursday, November 15, 2018 1:33 AM
> To: Burdick, Cliff; Bruce Richardson
> Cc: Thomas Monjalon; Burakov, Anatoly; dev@dpdk.org
> Subject: Re: [dpdk-dev] [PATCH 1/1] eal: Don't fail secondary if primary is missing tailqs
> 
> > On Wed, 2018-11-14 at 18:24 +0000, Burdick, Cliff wrote:
> > > 
> > > -----Original Message-----
> > > From: Luca Boccassi [mailto:bluca@debian.org]
> > > Sent: Wednesday, November 14, 2018 10:15 AM
> > > To: Burdick, Cliff; Bruce Richardson
> > > Cc: Thomas Monjalon; Burakov, Anatoly; dev@dpdk.org
> > > Subject: Re: [dpdk-dev] [PATCH 1/1] eal: Don't fail secondary if 
> > > primary is missing tailqs
> > > 
> > > > On Wed, 2018-11-14 at 17:40 +0000, Burdick, Cliff wrote:
> > > > > 
> > > > > -----Original Message-----
> > > > > From: Bruce Richardson [mailto:bruce.richardson@intel.com]
> > > > > Sent: Wednesday, November 14, 2018 3:48 AM
> > > > > To: Burdick, Cliff
> > > > > Cc: Thomas Monjalon; Burakov, Anatoly; dev@dpdk.org
> > > > > Subject: Re: [dpdk-dev] [PATCH 1/1] eal: Don't fail secondary if 
> > > > > primary is missing tailqs
> > > > > 
> > > > > On Tue, Nov 13, 2018 at 11:42:51PM +0000, Burdick, Cliff wrote:
> > > > > > > 
> > > > > > > ________________________________________
> > > > > > > From: Thomas Monjalon [thomas@monjalon.net]
> > > > > > > Sent: Tuesday, November 13, 2018 2:18 PM
> > > > > > > To: Burdick, Cliff
> > > > > > > Cc: Burakov, Anatoly; dev@dpdk.org; bruce.richardson@intel.co 
> > > > > > > m
> > > > > > > Subject: Re: [dpdk-dev] [PATCH 1/1] eal: Don't fail secondary 
> > > > > > > if primary is missing tailqs
> > > > > > > 
> > > > > > > 13/11/2018 23:08, Burdick, Cliff:
> > > > > > > > From: Thomas Monjalon [mailto:thomas@monjalon.net]
> > > > > > > > > 13/11/2018 17:38, Burdick, Cliff:
> > > > > > > > > > From: Thomas Monjalon [mailto:thomas@monjalon.net]
> > > > > > > > > > 13/11/2018 16:45, Burdick, Cliff:
> > > > > > > > > > > From: Burakov, Anatoly [mailto:anatoly.burakov@intel.
> > > > > > > > > > > com]
> > > > > > > > > > > > On 13-Nov-18 9:21 AM, Thomas Monjalon wrote:
> > > > > > > > > > > > > 13/11/2018 00:33, Burdick, Cliff:
> > > > > > > > > > > > > > This patch was submitted by Jean Tourrilhes over 
> > > > > > > > > > > > > > two years ago, but didn't receive any responses. 
> > > > > > > > > > > > > > I hit the same issue recently when trying to use 
> > > > > > > > > > > > > > cgo
> > > > > > > > > > > > > > (Golang) as a primary process linked to 
> > > > > > > > > > > > > > libdpdk.a against a C++ application linked 
> > > > > > > > > > > > > > against the same library.> > >
> > > > > > > > > > > > > 
> > > > > > > > > > > > > The question is to know why you don't have the 
> > > > > > > > > > > > > same constructors in primary and seconday?
> > > > > > > > > > > > 
> > > > > > > > > > > > I've hit similar things in the past. I believe it 
> > > > > > > > > > > > was caused by our build system stripping out unused 
> > > > > > > > > > > > libraries (such as
> > > > > > > > > > > > rte_hash) from the binary and thus not calling the 
> > > > > > > > > > > > constructor in the primary, but doing so in the 
> > > > > > > > > > > > secondary (or something to that effect). In any 
> > > > > > > > > > > > case, this is caused by linking different number of 
> > > > > > > > > > > > libraries to primary and secondary, and should 
> > > > > > > > > > > > probably be fixed in the build system, not in the 
> > > > > > > > > > > > tailqs code (unless we specifically support having 
> > > > > > > > > > > > different linked libraries to primary and 
> > > > > > > > > > > > secondary?).> > > >
> > > > > > > > > > > 
> > > > > > > > > > > Right, I think the original author of the patch stated 
> > > > > > > > > > > the reasons in the link I provided. The build system 
> > > > > > > > > > > seems like the most appropriate place to fix it, but 
> > > > > > > > > > > the patch got me going quickly. I think the question 
> > > > > > > > > > > is whether you want DPDK to support these other ways 
> > > > > > > > > > > of linking.
> > > > > > > > > > > I'm
> > > > > > > > > > > certainly not the first to use cgo, since there's a 
> > > > > > > > > > > virtual switch project doing the same:
> > > > > > > > > > > 
> > > > > > > > > > > https://urldefense.proofpoint.com/v2/url?u=https-3A__
> > > > > > > > > > > gith
> > > > > > > > > > > ub.co
> > > > > > > > > > > m_lago
> > > > > > > > > > > pu
> > > > > > > > > > > s_vsw&d=DwICAg&c=jcv3orpCsv7C4ly8-
> > > > > > > > > > > ubDoUfrxF5xIGWmptxGWP5vi5w&r =m1RLQ OG
> > > > > > > > > > > Okz9MauvVLZmiGtyWc5mA7DejbPFNE1IDj-
> > > > > > > > > > > 4&m=hQqVCNwW7eoEzB_hLFK97i8 idS8FI qX
> > > > > > > > > > > oPeclwsIZq7Y&s=BMoBlwkqljwWIBY3SE3pPMCfVnOUlDuZLrno4-
> > > > > > > > > > > SojKM&e=
> > > > > > > > > > > 
> > > > > > > > > > > They don't use primary/secondary processes, though, so 
> > > > > > > > > > > the issue is  never hit. I'm in a situation where 
> > > > > > > > > > > using cgo seemed like the easiest  path to accomplish 
> > > > > > > > > > > what I'm doing since I needed specialized  libraries 
> > > > > > > > > > > for it that were not available in C/C++. At some point 
> > > > > > > > > > > I  bet someone would use Cython to start linking 
> > > > > > > > > > > against DPDK as well,  and we'd likely run into the 
> > > > > > > > > > > same issue.> > > > For sure, we want to support using 
> > > > > > > > > > > DPDK with cgo or cython.
> > > > > > > > > > > But it is not clear what is the relation with not 
> > > > > > > > > > > having the same compilation for primary and secondary.
> > > > > > > > > > > Please
> > > > > > > > > > > could you elaborate?> > >
> > > > > > > > > > 
> > > > > > > > > > Hi Thomas, I think Jean explained it well here:
> > > > > > > > > > https://urldefense.proofpoint.com/v2/url?u=https-3A__de
> > > > > > > > > > v.dp
> > > > > > > > > > dk.narkive.
> > > > > > > > > > com_ZM3a7QD1_dpdk-2Ddev-2Dbug-2Dstatic-2Dconstructors-
> > > > > > > > > > 2Dconsider
> > > > > > > > > > ed-2De
> > > > > > > > > > vil&d=DwICAg&c=jcv3orpCsv7C4ly8- 
> > > > > > > > > > ubDoUfrxF5xIGWmptxGWP5vi5w&r=m1R LQOGOk
> > > > > > > > > > z9MauvVLZmiGtyWc5mA7DejbPFNE1IDj- 
> > > > > > > > > > 4&m=C69wDgrjDX8_oXp1M_3bnmWOOZd GqwBBG 
> > > > > > > > > > 9vzkyGDWGQ&s=YYn2N7WrzJpH1ptNrLZad0nPAQdrUyqBckk2uFuWYP
> > > > > > > > > > Q&e=
> > > > > > > > > > 
> > > > > > > > > > "The build system of the application does not have all 
> > > > > > > > > > the subtelties of the DPDK build system, and ends up 
> > > > > > > > > > including
> > > > > > > > > > *all*
> > > > > > > > > > the constructors, wether they are used or not in the 
> > > > > > > > > > code.
> > > > > > > > > > Moreover, they are included in a different order.
> > > > > > > > > > Actually,
> > > > > > > > > > by default the builds include no constructors at all 
> > > > > > > > > > (which is a big fail), so the library needs to be 
> > > > > > > > > > included with --whole-archive (see Snort DPDK 
> > > > > > > > > > instructions)."
> > > > > > > > > > 
> > > > > > > > > > I will get to the bottom of my exact case to understand 
> > > > > > > > > > what's happening, but my primary application is a cgo 
> > > > > > > > > > application that I'm linking to by using almost exactly 
> > > > > > > > > > the same flags that are used in the DPDK build system to 
> > > > > > > > > > build examples. The DPDK libraries I'm linking against 
> > > > > > > > > > is a single location for both primary and secondary; in 
> > > > > > > > > > other words, I don't build DPDK twice.
> > > > > > > > > > 
> > > > > > > > > > OK I understand, thanks.
> > > > > > > > > > 
> > > > > > > > > > You had alluded to a pkg-config for DPDK in the 2015 
> > > > > > > > > > thread, which cgo can use, but I don't know if that ever 
> > > > > > > > > > was implemented. Cgo can use pkg-config if it's 
> > > > > > > > > > available, otherwise the only tools are specifying 
> > > > > > > > > > LDFLAGS and CFLAGS into their build system.
> > > > > > > > > 
> > > > > > > > > Yes, the right answer is still pkg-config :) The good news 
> > > > > > > > > is that it is now implemented thanks to the meson build
> > > > > > > > > system:
> > > > > > > > >     
> > > > > > > > > https://urldefense.proofpoint.com/v2/url?u=http-3A__git.d
> > > > > > > > > pdk.
> > > > > > > > > org_dp
> > > > > > > > > dk_tree_doc_build-2Dsdk-2Dmeson.txt-
> > > > > > > > > 23n182&d=DwICAg&c=jcv3orpCsv7C4
> > > > > > > > > ly8-
> > > > > > > > > ubDoUfrxF5xIGWmptxGWP5vi5w&r=m1RLQOGOkz9MauvVLZmiGtyWc5mA
> > > > > > > > > 7Dej
> > > > > > > > > bP
> > > > > > > > > FNE1IDj-
> > > > > > > > > > 4&m=C69wDgrjDX8_oXp1M_3bnmWOOZdGqwBBG9vzkyGDWGQ&s=oC86K
> > > > > > > > > > D_R
> > > > > > > > > 
> > > > > > > > > J1T6rfzi3x5zFT1Ri13ELpKmsyFqpgDbgFg&e=
> > > > > > > > 
> > > > > > > > Hi Thomas, are there instructions on how to use pkg-config 
> > > > > > > > to build the mlx4/5 PMD? I noticed a patch was submitted in 
> > > > > > > > September to add support for it, but that link you provided 
> > > > > > > > on using meson doesn't say how to build specific drivers. It 
> > > > > > > > appears to be disabled by default.
> > > > > > > > If the dependency is found, meson will enable the PMD when 
> > > > > > > > building DPDK.
> > > > > > > 
> > > > > > > Do you know where exactly that is? I've been using mlx5 for a 
> > > > > > > while on this system, and I can see that 18.11-rc2 meson
> > > > > > > build+ninja built the pmd, but it's not on the --libs listing
> > > > > > > for
> > > > > > > pkg-config. Does it tell me what I was missing?
> > > > > > > 
> > > > > > 
> > > > > > For dynamic linking of applications, the drivers are not 
> > > > > > normally linked in. Instead, they should be loaded from the 
> > > > > > drivers directory as .so files
> > > > > > - normally by default in EAL as the driver .so's should be 
> > > > > > copied to the EAL_PMD_PATH where EAL finds them automatically. 
> > > > > > [This applies to both meson and make builds, though only meson 
> > > > > > generates the .pc file for pkg-config]
> > > > > > 
> > > > > > If you are doing a static build, then you need to explicitly 
> > > > > > link in the drivers. You can get a list from pkg-config using 
> > > > > > the "
> > > > > > --static" flag in this case. A good example of how to use pkg- 
> > > > > > config in this way can be found in the Makefiles for most 
> > > > > > examples, e.g. examples/helloworld/Makefile, reproduced below.
> > > > > > 
> > > > > > Regards,
> > > > > > /Bruce
> > > > > > 
> > > > > > all: shared
> > > > > > .PHONY: shared static
> > > > > > shared: build/$(APP)-shared
> > > > > >         ln -sf $(APP)-shared build/$(APP)
> > > > > > static: build/$(APP)-static
> > > > > >         ln -sf $(APP)-static build/$(APP)
> > > > > > 
> > > > > > PC_FILE := $(shell pkg-config --path libdpdk) CFLAGS += -O3 
> > > > > > $(shell pkg-config --cflags libdpdk) LDFLAGS_SHARED = $(shell 
> > > > > > pkg- config -- libs libdpdk) LDFLAGS_STATIC = -Wl,-Bstatic 
> > > > > > $(shell pkg-config
> > > > > > --
> > > > > > static --libs libdpdk)
> > > > > > 
> > > > > > build/$(APP)-shared: $(SRCS-y) Makefile $(PC_FILE) | build
> > > > > >         $(CC) $(CFLAGS) $(SRCS-y) -o $@ $(LDFLAGS)
> > > > > > $(LDFLAGS_SHARED)
> > > > > > 
> > > > > > build/$(APP)-static: $(SRCS-y) Makefile $(PC_FILE) | build
> > > > > >         $(CC) $(CFLAGS) $(SRCS-y) -o $@ $(LDFLAGS)
> > > > > > $(LDFLAGS_STATIC)
> > > > > > 
> > > > > > build:
> > > > > >         @mkdir -p $@
> > > > > 
> > > > > Thanks Bruce. I tried getting this to compile using cgo, and it's 
> > > > > causing more pain than it's worth. I used the --static --libs 
> > > > > options, and there were still numerous linker errors, some 
> > > > > specific to mlx, and some not. Specifically libmlx5 and libmnl are 
> > > > > both needed, but they're not part of the linker line from 
> > > > > pkg-config. At this point I'll just break the Go application up 
> > > > > into a separate C application that handles all the DPDK parts, and 
> > > > > send messages between them.
> > > > 
> > > > Hi,
> > > > 
> > > > As far as I can see, both mnl and mlx5 (and all the other reverse
> > > > dependencies) are listed correctly in the libdpdk.pc Libs.private 
> > > > entry, and pkg-config --libs --static libdpdk.pc does print them as 
> > > > intended. This is with 18.11-rc3.
> > > > Are you sure everything is correct (pkg-config path is right, -- 
> > > > static is used, etc)?
> > > > 
> > > > --
> > > > Kind regards,
> > > > Luca Boccassi
> > > 
> > > Hi Luca, here is what pkg-config gives:
> > > 
> > > PKG_CONFIG_PATH=meson-private/ pkg-config --libs --static libdpdk 
> > > -L/usr/local/lib/x86_64-linux-gnu -lrte_eventdev -lrte_power 
> > > -lrte_ip_frag -lrte_hash -lrte_pdump -lrte_eal -lrte_pipeline 
> > > -lrte_table -lrte_bbdev -lrte_bpf -lrte_vhost -lrte_metrics 
> > > -lrte_jobstats -lrte_net -lrte_reorder -lrte_ring -lrte_mempool 
> > > -lrte_security -lrte_compressdev -lrte_rawdev -lrte_mbuf -lrte_kvargs 
> > > -lrte_port -lrte_pci -lrte_ethdev -lrte_gro -lrte_gso -lrte_cryptodev 
> > > -lrte_sched -lrte_latencystats -lrte_efd -lrte_distributor -lrte_meter 
> > > -lrte_acl -lrte_member -lrte_cmdline -lrte_lpm -lrte_kni -lrte_cfgfile 
> > > -lrte_bitratestats -lrte_timer -lrte_flow_classify 
> > > -lrte_mempool_bucket -lrte_pmd_null_crypto -lrte_pmd_failsafe 
> > > -lrte_bus_ifpga -lrte_pmd_atlantic -lrte_pmd_mlx4 -lrte_pmd_vmxnet3 
> > > -lrte_pmd_avp -lrte_common_dpaax -lrte_pmd_ena -lcrypto 
> > > -lrte_bus_fslmc -ldl -lrte_pmd_avf -lrte_pmd_crypto_scheduler 
> > > -lrte_pmd_netvsc -lrte_pmd_vhost -lrte_bus_dpaa -lrte_mempool_dpaa2 
> > > -lrte_common_octeontx -lrte_pmd_liquidio -lrte_pmd_ifc -Wl,-Bdynamic 
> > > -lnuma -lrte_pmd_enic -lrte_common_cpt -pthread 
> > > -lrte_pmd_octeontx_crypto -lrte_pmd_qat -lrte_bus_vmbus -lrte_pmd_null 
> > > -lm -lrte_pmd_dpaa -lrte_bus_vdev -lrte_pmd_dpaa2 
> > > -lrte_pmd_skeleton_event -lrte_pmd_af_packet -lrte_pmd_octeontx 
> > > -lrte_pmd_thunderx -lrte_pmd_ring -lrte_pmd_octeontx_event 
> > > -lrte_pmd_sw_event -lrte_pmd_ark -lrte_mempool_octeontx 
> > > -lrte_pmd_ixgbe -lrte_pmd_kni -lrte_mempool_ring 
> > > -lrte_pmd_virtio_crypto -lrte_mempool_dpaa -lrte_pmd_dpaa2_cmdif 
> > > -lrte_bus_pci -lrte_pmd_opdl_event -lrte_pmd_mlx5 -lrte_pmd_virtio 
> > > -lrte_pmd_tap -lrte_pmd_caam_jr -lrte_pmd_dpaa2_sec 
> > > -lrte_pmd_dpaa2_qdma -lrte_pmd_enetc -lrte_pmd_sfc -lrte_pmd_bnxt 
> > > -lrte_pmd_dpaa2_event -lrte_pmd_cxgbe -Wl,--whole-archive -Wl,--no- 
> > > as-needed -lrte_pmd_e1000 -lrte_pmd_softnic -lrte_pmd_bond 
> > > -lrte_pmd_fm10k -lrte_pmd_i40e -lrte_pmd_nfp -lrte_pmd_qede -Wl,--no- 
> > > whole-archive -lrte_pmd_axgbe -lrte_pmd_ccp -lrte_pmd_ifpga_rawdev 
> > > -lrte_pmd_bbdev_null -lrte_pmd_openssl -lrte_pmd_dsw_event 
> > > -lrte_pmd_dpaa_event -lrte_mempool_stack -lrte_pmd_vdev_netvsc 
> > > -lrte_pmd_dpaa_sec -lrte_pmd_skeleton_rawdev 
> > > -lrte_pmd_octeontx_compress
> > > 
> > > You'll notice there's no mlx5 or mnl in that list. I was using 18.11-
> > > rc2 since I cloned early yesterday. Perhaps meson determined not to 
> > > put it in there for some reason?
> > 
> > Were mlx5/mnl found at meson configure time?
> > 
> > --
> > Kind regards,
> > Luca Boccassi
> 
> Hi Luca, yes, it was:
> 
> Library mnl found: YES
> Library mlx4 found: YES
> Library ibverbs found: YES
> Compiler for C supports argument -Wextra: YES
> Compiler for C supports argument -std=c11: YES
> Compiler for C supports argument -Wno-strict-prototypes: YES
> Compiler for C supports argument -D_BSD_SOURCE: YES
> Compiler for C supports argument -D_DEFAULT_SOURCE: YES
> Compiler for C supports argument -D_XOPEN_SOURCE=600: YES
> Checking whether type "struct mlx4_wqe_lso_seg" has member "mss_hdr_size": YES
> Configuring mlx4_autoconf.h using configuration
> Library mnl found: YES
> Library mlx5 found: YES
> Library ibverbs found: YES
> ...
> PKG_CONFIG_PATH=meson-private/ pkg-config --libs --static libdpdk
> -L/usr/local/lib/x86_64-linux-gnu -lrte_eventdev -lrte_power -lrte_ip_frag -lrte_hash -lrte_pdump -lrte_eal -lrte_pipeline -lrte_table -lrte_bbdev -lrte_bpf -lrte_vhost -lrte_metrics -lrte_jobstats -lrte_net -lrte_reorder -lrte_ring -lrte_mempool -lrte_security -lrte_compressdev -lrte_rawdev -lrte_mbuf -lrte_kvargs -lrte_port -lrte_pci -lrte_ethdev -lrte_gro -lrte_gso -lrte_cryptodev -lrte_sched -lrte_latencystats -lrte_efd -lrte_distributor -lrte_meter -lrte_acl -lrte_member -lrte_cmdline -lrte_lpm -lrte_kni -lrte_cfgfile -lrte_bitratestats -lrte_timer -lrte_flow_classify -lrte_pmd_ccp -lrte_mempool_bucket -lrte_pmd_failsafe -lrte_pmd_netvsc -lrte_pmd_null_crypto -lrte_bus_ifpga -lrte_pmd_atlantic -lrte_pmd_octeontx_event -lrte_pmd_avp -lrte_pmd_mlx4 -lrte_common_dpaax -lrte_pmd_skeleton_rawdev -lrte_pmd_ena -lrte_pmd_opdl_event -lrte_bus_fslmc -lnuma -lrte_pmd_avf -lrte_pmd_crypto_scheduler -lrte_pmd_vhost -lrte_bus_dpaa -lrte_mempool_dpaa2 -lrte_common_octeontx -Wl,--no-as-needed -lcrypto -lrte_pmd_ifc -lrte_pmd_liquidio -lrte_pmd_enic -lrte_common_cpt -Wl,--no-whole-archive -lrte_bus_vmbus -lrte_pmd_octeontx_crypto -lrte_pmd_qat -lrte_pmd_ifpga_rawdev -lrte_pmd_dpaa -lrte_bus_vdev -lrte_pmd_bbdev_null -lrte_pmd_dpaa2 -lrte_pmd_skeleton_event -lrte_pmd_ring -lrte_pmd_af_packet -lrte_pmd_thunderx -lrte_pmd_dpaa_event -lrte_pmd_octeontx_compress -lrte_pmd_dpaa_sec -lrte_pmd_sw_event -Wl,--whole-archive -lrte_pmd_ark -lrte_mempool_octeontx -lrte_pmd_ixgbe -lrte_mempool_ring -lrte_pmd_kni -lrte_pmd_vmxnet3 -lrte_mempool_dpaa -lrte_bus_pci -lrte_pmd_dpaa2_cmdif -lrte_pmd_mlx5 -lrte_pmd_tap -lrte_pmd_caam_jr -lrte_pmd_dpaa2_sec -lm -lrte_pmd_dpaa2_qdma -lrte_pmd_enetc -lrte_pmd_virtio -lrte_pmd_bnxt -lrte_pmd_dpaa2_event -lrte_pmd_sfc -lrte_pmd_cxgbe -pthread -lrte_pmd_e1000 -lrte_pmd_softnic -ldl -lrte_pmd_null -lrte_pmd_bond -lrte_pmd_fm10k -lrte_pmd_i40e -lrte_pmd_nfp -lrte_pmd_qede -lrte_pmd_axgbe -Wl,-Bdynamic -lrte_pmd_openssl -lrte_pmd_octeontx -lrte_pmd_dsw_event -lrte_mempool_stack -lrte_pmd_virtio_crypto -lrte_pmd_vdev_netvsc

Is this with latest DPDK from git? because I see the exact same as Luca:

$ PKG_CONFIG_PATH=build/meson-private/ pkg-config --libs --static libdpdk | grep mlx
-L/usr/local/lib64 -lrte_telemetry -lrte_bpf -lrte_flow_classify -lrte_pipeline -lrte_table -lrte_port -lrte_vhost -lrte_security -lrte_sched -lrte_reorder -lrte_rawdev -lrte_pdump -lrte_power -lrte_meter -lrte_member -lrte_lpm -lrte_latencystats -lrte_kni -lrte_jobstats -lrte_ip_frag -lrte_gso -lrte_gro -lrte_eventdev -lrte_efd -lrte_distributor -lrte_cryptodev -lrte_compressdev -lrte_cfgfile -lrte_bitratestats -lrte_bbdev -lrte_acl -lrte_timer -lrte_hash -lrte_metrics -lrte_pci -lrte_ethdev -lrte_net -lrte_mbuf -lrte_mempool -lrte_ring -lrte_eal -lrte_kvargs -lrte_cmdline -L/usr/local/lib64 -lrte_kvargs -lrte_eal -lrte_ring -lrte_mempool -lrte_mbuf -lrte_pci -lrte_cryptodev -lrte_net -lrte_cmdline -lrte_ethdev -lrte_hash -lrte_timer -lrte_common_dpaax -lrte_eventdev -lrte_rawdev -lrte_bus_dpaa -lrte_bus_fslmc -lrte_bus_pci -lrte_common_octeontx -lrte_bus_vdev -lrte_meter -lrte_sched -lrte_ip_frag -lz -lrte_mempool_dpaa -lrte_mempool_dpaa2 -lrte_vhost -lrte_security -lrte_kni -lmnl -lmlx4 -libverbs -lmnl -lmlx5 -libverbs -lrte_bus_vmbus -lrte_mempool_octeontx -lpcap -lrte_port -lrte_lpm -lrte_acl -lrte_table -lrte_pipeline -lsze2 -lrte_gso -lIPSec_MB -lIPSec_MB -lrte_common_cpt -lrte_reorder -lrte_compressdev -lrte_pmd_dpaa -lrte_pmd_dpaa2 -lrte_pmd_dpaa2_sec -lrte_pmd_octeontx -lrte_bbdev -lrte_bus_ifpga -Wl,--whole-archive -lrte_mempool_bucket -lrte_mempool_ring -lrte_mempool_stack -lrte_pmd_af_packet -lrte_pmd_ark -lrte_pmd_atlantic -lrte_pmd_avf -lrte_pmd_avp -lrte_pmd_axgbe -lrte_pmd_bond -lrte_pmd_bnx2x -lrte_pmd_bnxt -lrte_pmd_cxgbe -lrte_pmd_e1000 -lrte_pmd_ena -lrte_pmd_enetc -lrte_pmd_enic -lrte_pmd_failsafe -lrte_pmd_fm10k -lrte_pmd_i40e -lrte_pmd_ifc -lrte_pmd_ixgbe -lrte_pmd_kmod -lrte_pmd_kni -lrte_pmd_liquidio -lrte_pmd_mlx4 -lrte_pmd_mlx5 -lrte_pmd_netvsc -lrte_pmd_nfp -lrte_pmd_null -lrte_pmd_pcap -lrte_pmd_qede -lrte_pmd_ring -lrte_pmd_sfc -lrte_pmd_softnic -lrte_pmd_szedata2 -lrte_pmd_tap -lrte_pmd_thunderx -lrte_pmd_vdev_netvsc -lrte_pmd_vhost -lrte_pmd_virtio -lrte_pmd_vmxnet3 -lrte_pmd_aesni_gcm -lrte_pmd_aesni_mb -lrte_pmd_caam_jr -lrte_pmd_ccp -lrte_pmd_dpaa_sec -lrte_pmd_null_crypto -lrte_pmd_octeontx_crypto -lrte_pmd_openssl -lrte_pmd_crypto_scheduler -lrte_pmd_virtio_crypto -lrte_pmd_octeontx_compress -lrte_pmd_qat -lrte_pmd_zlib -lrte_pmd_dpaa_event -lrte_pmd_dpaa2_event -lrte_pmd_octeontx_event -lrte_pmd_opdl_event -lrte_pmd_skeleton_event -lrte_pmd_sw_event -lrte_pmd_dsw_event -lrte_pmd_bbdev_null -lrte_pmd_skeleton_rawdev -lrte_pmd_dpaa2_cmdif -lrte_pmd_dpaa2_qdma -lrte_pmd_ifpga_rawdev -lrte_pmd_ioat_copy -Wl,--no-whole-archive -Wl,-Bdynamic -Wl,--no-as-needed -pthread -lm -ldl -lnuma -lbsd -lpcap -lcrypto -lcrypto -lz -lcrypto -ldl -pthread -lz

Re: [dpdk-dev] [PATCH 1/1] eal: Don't fail secondary if primary is missing tailqs

[Burdick, Cliff]

-----Original Message-----
From: Bruce Richardson [mailto:bruce.richardson@intel.com] 
Sent: Thursday, November 15, 2018 8:41 AM
To: Burdick, Cliff
Cc: Luca Boccassi; Thomas Monjalon; Burakov, Anatoly; dev@dpdk.org
Subject: Re: [dpdk-dev] [PATCH 1/1] eal: Don't fail secondary if primary is missing tailqs

> On Thu, Nov 15, 2018 at 04:15:36PM +0000, Burdick, Cliff wrote:
> > 
> > 
> > -----Original Message-----
> > From: Luca Boccassi [mailto:bluca@debian.org]
> > Sent: Thursday, November 15, 2018 1:33 AM
> > To: Burdick, Cliff; Bruce Richardson
> > Cc: Thomas Monjalon; Burakov, Anatoly; dev@dpdk.org
> > Subject: Re: [dpdk-dev] [PATCH 1/1] eal: Don't fail secondary if 
> > primary is missing tailqs
> > 
> > > On Wed, 2018-11-14 at 18:24 +0000, Burdick, Cliff wrote:
> > > > 
> > > > -----Original Message-----
> > > > From: Luca Boccassi [mailto:bluca@debian.org]
> > > > Sent: Wednesday, November 14, 2018 10:15 AM
> > > > To: Burdick, Cliff; Bruce Richardson
> > > > Cc: Thomas Monjalon; Burakov, Anatoly; dev@dpdk.org
> > > > Subject: Re: [dpdk-dev] [PATCH 1/1] eal: Don't fail secondary if 
> > > > primary is missing tailqs
> > > > 
> > > > > On Wed, 2018-11-14 at 17:40 +0000, Burdick, Cliff wrote:
> > > > > > 
> > > > > > -----Original Message-----
> > > > > > From: Bruce Richardson [mailto:bruce.richardson@intel.com]
> > > > > > Sent: Wednesday, November 14, 2018 3:48 AM
> > > > > > To: Burdick, Cliff
> > > > > > Cc: Thomas Monjalon; Burakov, Anatoly; dev@dpdk.org
> > > > > > Subject: Re: [dpdk-dev] [PATCH 1/1] eal: Don't fail secondary 
> > > > > > if primary is missing tailqs
> > > > > > 
> > > > > > On Tue, Nov 13, 2018 at 11:42:51PM +0000, Burdick, Cliff wrote:
> > > > > > > > 
> > > > > > > > ________________________________________
> > > > > > > > From: Thomas Monjalon [thomas@monjalon.net]
> > > > > > > > Sent: Tuesday, November 13, 2018 2:18 PM
> > > > > > > > To: Burdick, Cliff
> > > > > > > > Cc: Burakov, Anatoly; dev@dpdk.org; 
> > > > > > > > bruce.richardson@intel.co m
> > > > > > > > Subject: Re: [dpdk-dev] [PATCH 1/1] eal: Don't fail 
> > > > > > > > secondary if primary is missing tailqs
> > > > > > > > 
> > > > > > > > 13/11/2018 23:08, Burdick, Cliff:
> > > > > > > > > From: Thomas Monjalon [mailto:thomas@monjalon.net]
> > > > > > > > > > 13/11/2018 17:38, Burdick, Cliff:
> > > > > > > > > > > From: Thomas Monjalon [mailto:thomas@monjalon.net]
> > > > > > > > > > > 13/11/2018 16:45, Burdick, Cliff:
> > > > > > > > > > > > From: Burakov, Anatoly [mailto:anatoly.burakov@intel.
> > > > > > > > > > > > com]
> > > > > > > > > > > > > On 13-Nov-18 9:21 AM, Thomas Monjalon wrote:
> > > > > > > > > > > > > > 13/11/2018 00:33, Burdick, Cliff:
> > > > > > > > > > > > > > > This patch was submitted by Jean Tourrilhes 
> > > > > > > > > > > > > > > over two years ago, but didn't receive any responses.
> > > > > > > > > > > > > > > I hit the same issue recently when trying to 
> > > > > > > > > > > > > > > use cgo
> > > > > > > > > > > > > > > (Golang) as a primary process linked to 
> > > > > > > > > > > > > > > libdpdk.a against a C++ application linked 
> > > > > > > > > > > > > > > against the same library.> > >
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > The question is to know why you don't have the 
> > > > > > > > > > > > > > same constructors in primary and seconday?
> > > > > > > > > > > > > 
> > > > > > > > > > > > > I've hit similar things in the past. I believe 
> > > > > > > > > > > > > it was caused by our build system stripping out 
> > > > > > > > > > > > > unused libraries (such as
> > > > > > > > > > > > > rte_hash) from the binary and thus not calling 
> > > > > > > > > > > > > the constructor in the primary, but doing so in 
> > > > > > > > > > > > > the secondary (or something to that effect). In 
> > > > > > > > > > > > > any case, this is caused by linking different 
> > > > > > > > > > > > > number of libraries to primary and secondary, 
> > > > > > > > > > > > > and should probably be fixed in the build 
> > > > > > > > > > > > > system, not in the tailqs code (unless we 
> > > > > > > > > > > > > specifically support having different linked 
> > > > > > > > > > > > > libraries to primary and secondary?).> > > >
> > > > > > > > > > > > 
> > > > > > > > > > > > Right, I think the original author of the patch 
> > > > > > > > > > > > stated the reasons in the link I provided. The 
> > > > > > > > > > > > build system seems like the most appropriate place 
> > > > > > > > > > > > to fix it, but the patch got me going quickly. I 
> > > > > > > > > > > > think the question is whether you want DPDK to 
> > > > > > > > > > > > support these other ways of linking.
> > > > > > > > > > > > I'm
> > > > > > > > > > > > certainly not the first to use cgo, since there's 
> > > > > > > > > > > > a virtual switch project doing the same:
> > > > > > > > > > > > 
> > > > > > > > > > > > https://urldefense.proofpoint.com/v2/url?u=https-3
> > > > > > > > > > > > A__
> > > > > > > > > > > > gith
> > > > > > > > > > > > ub.co
> > > > > > > > > > > > m_lago
> > > > > > > > > > > > pu
> > > > > > > > > > > > s_vsw&d=DwICAg&c=jcv3orpCsv7C4ly8-
> > > > > > > > > > > > ubDoUfrxF5xIGWmptxGWP5vi5w&r =m1RLQ OG
> > > > > > > > > > > > Okz9MauvVLZmiGtyWc5mA7DejbPFNE1IDj-
> > > > > > > > > > > > 4&m=hQqVCNwW7eoEzB_hLFK97i8 idS8FI qX
> > > > > > > > > > > > oPeclwsIZq7Y&s=BMoBlwkqljwWIBY3SE3pPMCfVnOUlDuZLrn
> > > > > > > > > > > > o4-
> > > > > > > > > > > > SojKM&e=
> > > > > > > > > > > > 
> > > > > > > > > > > > They don't use primary/secondary processes, 
> > > > > > > > > > > > though, so the issue is  never hit. I'm in a 
> > > > > > > > > > > > situation where using cgo seemed like the easiest  
> > > > > > > > > > > > path to accomplish what I'm doing since I needed 
> > > > > > > > > > > > specialized  libraries for it that were not 
> > > > > > > > > > > > available in C/C++. At some point I  bet someone 
> > > > > > > > > > > > would use Cython to start linking against DPDK as 
> > > > > > > > > > > > well,  and we'd likely run into the same issue.> > 
> > > > > > > > > > > > > > For sure, we want to support using DPDK with cgo or cython.
> > > > > > > > > > > > But it is not clear what is the relation with not 
> > > > > > > > > > > > having the same compilation for primary and secondary.
> > > > > > > > > > > > Please
> > > > > > > > > > > > could you elaborate?> > >
> > > > > > > > > > > 
> > > > > > > > > > > Hi Thomas, I think Jean explained it well here:
> > > > > > > > > > > https://urldefense.proofpoint.com/v2/url?u=https-3A_
> > > > > > > > > > > _de
> > > > > > > > > > > v.dp
> > > > > > > > > > > dk.narkive.
> > > > > > > > > > > com_ZM3a7QD1_dpdk-2Ddev-2Dbug-2Dstatic-2Dconstructor
> > > > > > > > > > > s-
> > > > > > > > > > > 2Dconsider
> > > > > > > > > > > ed-2De
> > > > > > > > > > > vil&d=DwICAg&c=jcv3orpCsv7C4ly8- 
> > > > > > > > > > > ubDoUfrxF5xIGWmptxGWP5vi5w&r=m1R LQOGOk
> > > > > > > > > > > z9MauvVLZmiGtyWc5mA7DejbPFNE1IDj- 
> > > > > > > > > > > 4&m=C69wDgrjDX8_oXp1M_3bnmWOOZd GqwBBG 
> > > > > > > > > > > 9vzkyGDWGQ&s=YYn2N7WrzJpH1ptNrLZad0nPAQdrUyqBckk2uFu
> > > > > > > > > > > WYP
> > > > > > > > > > > Q&e=
> > > > > > > > > > > 
> > > > > > > > > > > "The build system of the application does not have 
> > > > > > > > > > > all the subtelties of the DPDK build system, and 
> > > > > > > > > > > ends up including
> > > > > > > > > > > *all*
> > > > > > > > > > > the constructors, wether they are used or not in the 
> > > > > > > > > > > code.
> > > > > > > > > > > Moreover, they are included in a different order.
> > > > > > > > > > > Actually,
> > > > > > > > > > > by default the builds include no constructors at all 
> > > > > > > > > > > (which is a big fail), so the library needs to be 
> > > > > > > > > > > included with --whole-archive (see Snort DPDK 
> > > > > > > > > > > instructions)."
> > > > > > > > > > > 
> > > > > > > > > > > I will get to the bottom of my exact case to 
> > > > > > > > > > > understand what's happening, but my primary 
> > > > > > > > > > > application is a cgo application that I'm linking to 
> > > > > > > > > > > by using almost exactly the same flags that are used 
> > > > > > > > > > > in the DPDK build system to build examples. The DPDK 
> > > > > > > > > > > libraries I'm linking against is a single location 
> > > > > > > > > > > for both primary and secondary; in other words, I don't build DPDK twice.
> > > > > > > > > > > 
> > > > > > > > > > > OK I understand, thanks.
> > > > > > > > > > > 
> > > > > > > > > > > You had alluded to a pkg-config for DPDK in the 2015 
> > > > > > > > > > > thread, which cgo can use, but I don't know if that 
> > > > > > > > > > > ever was implemented. Cgo can use pkg-config if it's 
> > > > > > > > > > > available, otherwise the only tools are specifying 
> > > > > > > > > > > LDFLAGS and CFLAGS into their build system.
> > > > > > > > > > 
> > > > > > > > > > Yes, the right answer is still pkg-config :) The good 
> > > > > > > > > > news is that it is now implemented thanks to the meson 
> > > > > > > > > > build
> > > > > > > > > > system:
> > > > > > > > > >     
> > > > > > > > > > https://urldefense.proofpoint.com/v2/url?u=http-3A__gi
> > > > > > > > > > t.d
> > > > > > > > > > pdk.
> > > > > > > > > > org_dp
> > > > > > > > > > dk_tree_doc_build-2Dsdk-2Dmeson.txt-
> > > > > > > > > > 23n182&d=DwICAg&c=jcv3orpCsv7C4
> > > > > > > > > > ly8-
> > > > > > > > > > ubDoUfrxF5xIGWmptxGWP5vi5w&r=m1RLQOGOkz9MauvVLZmiGtyWc
> > > > > > > > > > 5mA
> > > > > > > > > > 7Dej
> > > > > > > > > > bP
> > > > > > > > > > FNE1IDj-
> > > > > > > > > > > 4&m=C69wDgrjDX8_oXp1M_3bnmWOOZdGqwBBG9vzkyGDWGQ&s=oC
> > > > > > > > > > > 86K
> > > > > > > > > > > D_R
> > > > > > > > > > 
> > > > > > > > > > J1T6rfzi3x5zFT1Ri13ELpKmsyFqpgDbgFg&e=
> > > > > > > > > 
> > > > > > > > > Hi Thomas, are there instructions on how to use 
> > > > > > > > > pkg-config to build the mlx4/5 PMD? I noticed a patch 
> > > > > > > > > was submitted in September to add support for it, but 
> > > > > > > > > that link you provided on using meson doesn't say how to 
> > > > > > > > > build specific drivers. It appears to be disabled by default.
> > > > > > > > > If the dependency is found, meson will enable the PMD 
> > > > > > > > > when building DPDK.
> > > > > > > > 
> > > > > > > > Do you know where exactly that is? I've been using mlx5 
> > > > > > > > for a while on this system, and I can see that 18.11-rc2 
> > > > > > > > meson
> > > > > > > > build+ninja built the pmd, but it's not on the --libs 
> > > > > > > > build+listing
> > > > > > > > for
> > > > > > > > pkg-config. Does it tell me what I was missing?
> > > > > > > > 
> > > > > > > 
> > > > > > > For dynamic linking of applications, the drivers are not 
> > > > > > > normally linked in. Instead, they should be loaded from the 
> > > > > > > drivers directory as .so files
> > > > > > > - normally by default in EAL as the driver .so's should be 
> > > > > > > copied to the EAL_PMD_PATH where EAL finds them automatically.
> > > > > > > [This applies to both meson and make builds, though only 
> > > > > > > meson generates the .pc file for pkg-config]
> > > > > > > 
> > > > > > > If you are doing a static build, then you need to explicitly 
> > > > > > > link in the drivers. You can get a list from pkg-config 
> > > > > > > using the "
> > > > > > > --static" flag in this case. A good example of how to use 
> > > > > > > pkg- config in this way can be found in the Makefiles for 
> > > > > > > most examples, e.g. examples/helloworld/Makefile, reproduced below.
> > > > > > > 
> > > > > > > Regards,
> > > > > > > /Bruce
> > > > > > > 
> > > > > > > all: shared
> > > > > > > .PHONY: shared static
> > > > > > > shared: build/$(APP)-shared
> > > > > > >         ln -sf $(APP)-shared build/$(APP)
> > > > > > > static: build/$(APP)-static
> > > > > > >         ln -sf $(APP)-static build/$(APP)
> > > > > > > 
> > > > > > > PC_FILE := $(shell pkg-config --path libdpdk) CFLAGS += -O3 
> > > > > > > $(shell pkg-config --cflags libdpdk) LDFLAGS_SHARED = 
> > > > > > > $(shell
> > > > > > > pkg- config -- libs libdpdk) LDFLAGS_STATIC = -Wl,-Bstatic 
> > > > > > > $(shell pkg-config
> > > > > > > --
> > > > > > > static --libs libdpdk)
> > > > > > > 
> > > > > > > build/$(APP)-shared: $(SRCS-y) Makefile $(PC_FILE) | build
> > > > > > >         $(CC) $(CFLAGS) $(SRCS-y) -o $@ $(LDFLAGS)
> > > > > > > $(LDFLAGS_SHARED)
> > > > > > > 
> > > > > > > build/$(APP)-static: $(SRCS-y) Makefile $(PC_FILE) | build
> > > > > > >         $(CC) $(CFLAGS) $(SRCS-y) -o $@ $(LDFLAGS)
> > > > > > > $(LDFLAGS_STATIC)
> > > > > > > 
> > > > > > > build:
> > > > > > >         @mkdir -p $@
> > > > > > 
> > > > > > Thanks Bruce. I tried getting this to compile using cgo, and 
> > > > > > it's causing more pain than it's worth. I used the --static 
> > > > > > --libs options, and there were still numerous linker errors, 
> > > > > > some specific to mlx, and some not. Specifically libmlx5 and 
> > > > > > libmnl are both needed, but they're not part of the linker 
> > > > > > line from pkg-config. At this point I'll just break the Go 
> > > > > > application up into a separate C application that handles all 
> > > > > > the DPDK parts, and send messages between them.
> > > > > 
> > > > > Hi,
> > > > > 
> > > > > As far as I can see, both mnl and mlx5 (and all the other 
> > > > > reverse
> > > > > dependencies) are listed correctly in the libdpdk.pc 
> > > > > Libs.private entry, and pkg-config --libs --static libdpdk.pc 
> > > > > does print them as intended. This is with 18.11-rc3.
> > > > > Are you sure everything is correct (pkg-config path is right, -- 
> > > > > static is used, etc)?
> > > > > 
> > > > > --
> > > > > Kind regards,
> > > > > Luca Boccassi
> > > > 
> > > > Hi Luca, here is what pkg-config gives:
> > > > 
> > > > PKG_CONFIG_PATH=meson-private/ pkg-config --libs --static libdpdk 
> > > > -L/usr/local/lib/x86_64-linux-gnu -lrte_eventdev -lrte_power 
> > > > -lrte_ip_frag -lrte_hash -lrte_pdump -lrte_eal -lrte_pipeline 
> > > > -lrte_table -lrte_bbdev -lrte_bpf -lrte_vhost -lrte_metrics 
> > > > -lrte_jobstats -lrte_net -lrte_reorder -lrte_ring -lrte_mempool 
> > > > -lrte_security -lrte_compressdev -lrte_rawdev -lrte_mbuf 
> > > > -lrte_kvargs -lrte_port -lrte_pci -lrte_ethdev -lrte_gro -lrte_gso 
> > > > -lrte_cryptodev -lrte_sched -lrte_latencystats -lrte_efd 
> > > > -lrte_distributor -lrte_meter -lrte_acl -lrte_member -lrte_cmdline 
> > > > -lrte_lpm -lrte_kni -lrte_cfgfile -lrte_bitratestats -lrte_timer 
> > > > -lrte_flow_classify -lrte_mempool_bucket -lrte_pmd_null_crypto 
> > > > -lrte_pmd_failsafe -lrte_bus_ifpga -lrte_pmd_atlantic 
> > > > -lrte_pmd_mlx4 -lrte_pmd_vmxnet3 -lrte_pmd_avp -lrte_common_dpaax 
> > > > -lrte_pmd_ena -lcrypto -lrte_bus_fslmc -ldl -lrte_pmd_avf 
> > > > -lrte_pmd_crypto_scheduler -lrte_pmd_netvsc -lrte_pmd_vhost 
> > > > -lrte_bus_dpaa -lrte_mempool_dpaa2 -lrte_common_octeontx 
> > > > -lrte_pmd_liquidio -lrte_pmd_ifc -Wl,-Bdynamic -lnuma 
> > > > -lrte_pmd_enic -lrte_common_cpt -pthread -lrte_pmd_octeontx_crypto 
> > > > -lrte_pmd_qat -lrte_bus_vmbus -lrte_pmd_null -lm -lrte_pmd_dpaa 
> > > > -lrte_bus_vdev -lrte_pmd_dpaa2 -lrte_pmd_skeleton_event 
> > > > -lrte_pmd_af_packet -lrte_pmd_octeontx -lrte_pmd_thunderx 
> > > > -lrte_pmd_ring -lrte_pmd_octeontx_event -lrte_pmd_sw_event 
> > > > -lrte_pmd_ark -lrte_mempool_octeontx -lrte_pmd_ixgbe -lrte_pmd_kni 
> > > > -lrte_mempool_ring -lrte_pmd_virtio_crypto -lrte_mempool_dpaa 
> > > > -lrte_pmd_dpaa2_cmdif -lrte_bus_pci -lrte_pmd_opdl_event 
> > > > -lrte_pmd_mlx5 -lrte_pmd_virtio -lrte_pmd_tap -lrte_pmd_caam_jr 
> > > > -lrte_pmd_dpaa2_sec -lrte_pmd_dpaa2_qdma -lrte_pmd_enetc 
> > > > -lrte_pmd_sfc -lrte_pmd_bnxt -lrte_pmd_dpaa2_event -lrte_pmd_cxgbe 
> > > > -Wl,--whole-archive -Wl,--no- as-needed -lrte_pmd_e1000 
> > > > -lrte_pmd_softnic -lrte_pmd_bond -lrte_pmd_fm10k -lrte_pmd_i40e 
> > > > -lrte_pmd_nfp -lrte_pmd_qede -Wl,--no- whole-archive 
> > > > -lrte_pmd_axgbe -lrte_pmd_ccp -lrte_pmd_ifpga_rawdev 
> > > > -lrte_pmd_bbdev_null -lrte_pmd_openssl -lrte_pmd_dsw_event 
> > > > -lrte_pmd_dpaa_event -lrte_mempool_stack -lrte_pmd_vdev_netvsc 
> > > > -lrte_pmd_dpaa_sec -lrte_pmd_skeleton_rawdev 
> > > > -lrte_pmd_octeontx_compress
> > > > 
> > > > You'll notice there's no mlx5 or mnl in that list. I was using 
> > > > 18.11-
> > > > rc2 since I cloned early yesterday. Perhaps meson determined not 
> > > > to put it in there for some reason?
> > > 
> > > Were mlx5/mnl found at meson configure time?
> > > 
> > > --
> > > Kind regards,
> > > Luca Boccassi
> > 
> > Hi Luca, yes, it was:
> > 
> > Library mnl found: YES
> > Library mlx4 found: YES
> > Library ibverbs found: YES
> > Compiler for C supports argument -Wextra: YES Compiler for C supports 
> > argument -std=c11: YES Compiler for C supports argument 
> > -Wno-strict-prototypes: YES Compiler for C supports argument 
> > -D_BSD_SOURCE: YES Compiler for C supports argument -D_DEFAULT_SOURCE: 
> > YES Compiler for C supports argument -D_XOPEN_SOURCE=600: YES Checking 
> > whether type "struct mlx4_wqe_lso_seg" has member "mss_hdr_size": YES 
> > Configuring mlx4_autoconf.h using configuration Library mnl found: YES 
> > Library mlx5 found: YES Library ibverbs found: YES ...
> > PKG_CONFIG_PATH=meson-private/ pkg-config --libs --static libdpdk 
> > -L/usr/local/lib/x86_64-linux-gnu -lrte_eventdev -lrte_power 
> > -lrte_ip_frag -lrte_hash -lrte_pdump -lrte_eal -lrte_pipeline 
> > -lrte_table -lrte_bbdev -lrte_bpf -lrte_vhost -lrte_metrics 
> > -lrte_jobstats -lrte_net -lrte_reorder -lrte_ring -lrte_mempool 
> > -lrte_security -lrte_compressdev -lrte_rawdev -lrte_mbuf -lrte_kvargs 
> > -lrte_port -lrte_pci -lrte_ethdev -lrte_gro -lrte_gso -lrte_cryptodev 
> > -lrte_sched -lrte_latencystats -lrte_efd -lrte_distributor -lrte_meter 
> > -lrte_acl -lrte_member -lrte_cmdline -lrte_lpm -lrte_kni -lrte_cfgfile 
> > -lrte_bitratestats -lrte_timer -lrte_flow_classify -lrte_pmd_ccp 
> > -lrte_mempool_bucket -lrte_pmd_failsafe -lrte_pmd_netvsc 
> > -lrte_pmd_null_crypto -lrte_bus_ifpga -lrte_pmd_atlantic 
> > -lrte_pmd_octeontx_event -lrte_pmd_avp -lrte_pmd_mlx4 
> > -lrte_common_dpaax -lrte_pmd_skeleton_rawdev -lrte_pmd_ena 
> > -lrte_pmd_opdl_event -lrte_bus_fslmc -lnuma -lrte_pmd_avf 
> > -lrte_pmd_crypto_scheduler -lrte_pmd_vhost -lrte_bus_dpaa 
> > -lrte_mempool_dpaa2 -lrte_common_octeontx -Wl,--no-as-needed -lcrypto 
> > -lrte_pmd_ifc -lrte_pmd_liquidio -lrte_pmd_enic -lrte_common_cpt 
> > -Wl,--no-whole-archive -lrte_bus_vmbus -lrte_pmd_octeontx_crypto 
> > -lrte_pmd_qat -lrte_pmd_ifpga_rawdev -lrte_pmd_dpaa -lrte_bus_vdev 
> > -lrte_pmd_bbdev_null -lrte_pmd_dpaa2 -lrte_pmd_skeleton_event 
> > -lrte_pmd_ring -lrte_pmd_af_packet -lrte_pmd_thunderx 
> > -lrte_pmd_dpaa_event -lrte_pmd_octeontx_compress -lrte_pmd_dpaa_sec 
> > -lrte_pmd_sw_event -Wl,--whole-archive -lrte_pmd_ark 
> > -lrte_mempool_octeontx -lrte_pmd_ixgbe -lrte_mempool_ring 
> > -lrte_pmd_kni -lrte_pmd_vmxnet3 -lrte_mempool_dpaa -lrte_bus_pci 
> > -lrte_pmd_dpaa2_cmdif -lrte_pmd_mlx5 -lrte_pmd_tap -lrte_pmd_caam_jr 
> > -lrte_pmd_dpaa2_sec -lm -lrte_pmd_dpaa2_qdma -lrte_pmd_enetc 
> > -lrte_pmd_virtio -lrte_pmd_bnxt -lrte_pmd_dpaa2_event -lrte_pmd_sfc 
> > -lrte_pmd_cxgbe -pthread -lrte_pmd_e1000 -lrte_pmd_softnic -ldl 
> > -lrte_pmd_null -lrte_pmd_bond -lrte_pmd_fm10k -lrte_pmd_i40e 
> > -lrte_pmd_nfp -lrte_pmd_qede -lrte_pmd_axgbe -Wl,-Bdynamic 
> > -lrte_pmd_openssl -lrte_pmd_octeontx -lrte_pmd_dsw_event 
> > -lrte_mempool_stack -lrte_pmd_virtio_crypto -lrte_pmd_vdev_netvsc
> 
> Is this with latest DPDK from git? because I see the exact same as Luca:
> 
> $ PKG_CONFIG_PATH=build/meson-private/ pkg-config --libs --static libdpdk | grep mlx
> -L/usr/local/lib64 -lrte_telemetry -lrte_bpf -lrte_flow_classify -lrte_pipeline -lrte_table -lrte_port -lrte_vhost -lrte_security -lrte_sched -lrte_reorder -lrte_rawdev -lrte_pdump -lrte_power -lrte_meter -lrte_member -lrte_lpm -lrte_latencystats -lrte_kni -lrte_jobstats -lrte_ip_frag -lrte_gso -lrte_gro -lrte_eventdev -lrte_efd -lrte_distributor -lrte_cryptodev -lrte_compressdev -lrte_cfgfile -lrte_bitratestats -lrte_bbdev -lrte_acl -lrte_timer -lrte_hash -lrte_metrics -lrte_pci -lrte_ethdev -lrte_net -lrte_mbuf -lrte_mempool -lrte_ring -lrte_eal -lrte_kvargs -lrte_cmdline -L/usr/local/lib64 -lrte_kvargs -lrte_eal -lrte_ring -lrte_mempool -lrte_mbuf -lrte_pci -lrte_cryptodev -lrte_net -lrte_cmdline -lrte_ethdev -lrte_hash -lrte_timer -lrte_common_dpaax -lrte_eventdev -lrte_rawdev -lrte_bus_dpaa -lrte_bus_fslmc -lrte_bus_pci -lrte_common_octeontx -lrte_bus_vdev -lrte_meter -lrte_sched -lrte_ip_frag -lz -lrte_mempool_dpaa -lrte_mempool_dpaa2 -lrte_vhost -lrte_security -lrte_kni -lmnl -lmlx4 -libverbs -lmnl -lmlx5 -libverbs -lrte_bus_vmbus -lrte_mempool_octeontx -lpcap -lrte_port -lrte_lpm -lrte_acl -lrte_table -lrte_pipeline -lsze2 -lrte_gso -lIPSec_MB -lIPSec_MB -lrte_common_cpt -lrte_reorder -lrte_compressdev -lrte_pmd_dpaa -lrte_pmd_dpaa2 -lrte_pmd_dpaa2_sec -lrte_pmd_octeontx -lrte_bbdev -lrte_bus_ifpga -Wl,--whole-archive -lrte_mempool_bucket -lrte_mempool_ring -lrte_mempool_stack -lrte_pmd_af_packet -lrte_pmd_ark -lrte_pmd_atlantic -lrte_pmd_avf -lrte_pmd_avp -lrte_pmd_axgbe -lrte_pmd_bond -lrte_pmd_bnx2x -lrte_pmd_bnxt -lrte_pmd_cxgbe -lrte_pmd_e1000 -lrte_pmd_ena -lrte_pmd_enetc -lrte_pmd_enic -lrte_pmd_failsafe -lrte_pmd_fm10k -lrte_pmd_i40e -lrte_pmd_ifc -lrte_pmd_ixgbe -lrte_pmd_kmod -lrte_pmd_kni -lrte_pmd_liquidio -lrte_pmd_mlx4 -lrte_pmd_mlx5 -lrte_pmd_netvsc -lrte_pmd_nfp -lrte_pmd_null -lrte_pmd_pcap -lrte_pmd_qede -lrte_pmd_ring -lrte_pmd_sfc -lrte_pmd_softnic -lrte_pmd_szedata2 -lrte_pmd_tap -lrte_pmd_thunderx -lrte_pmd_vdev_netvsc -lrte_pmd_vhost -lrte_pmd_virtio -lrte_pmd_vmxnet3 -lrte_pmd_aesni_gcm -lrte_pmd_aesni_mb -lrte_pmd_caam_jr -lrte_pmd_ccp -lrte_pmd_dpaa_sec -lrte_pmd_null_crypto -lrte_pmd_octeontx_crypto -lrte_pmd_openssl -lrte_pmd_crypto_scheduler -lrte_pmd_virtio_crypto -lrte_pmd_octeontx_compress -lrte_pmd_qat -lrte_pmd_zlib -lrte_pmd_dpaa_event -lrte_pmd_dpaa2_event -lrte_pmd_octeontx_event -lrte_pmd_opdl_event -lrte_pmd_skeleton_event -lrte_pmd_sw_event -lrte_pmd_dsw_event -lrte_pmd_bbdev_null -lrte_pmd_skeleton_rawdev -lrte_pmd_dpaa2_cmdif -lrte_pmd_dpaa2_qdma -lrte_pmd_ifpga_rawdev -lrte_pmd_ioat_copy -Wl,--no-whole-archive -Wl,-Bdynamic -Wl,--no-as-needed -pthread -lm -ldl -lnuma -lbsd -lpcap -lcrypto -lcrypto -lz -lcrypto -ldl -pthread -lz

Hi Bruce, I tried with rc3 and a new clone from right now, and get the same results:

$ meson build
The Meson build system
Version: 0.45.1
Source dir: /home/cburdick/dpdk
Build dir: /home/cburdick/dpdk/build
Build type: native build
Project name: DPDK
Native C compiler: cc (gcc 7.3.0 "cc (Ubuntu 7.3.0-27ubuntu1~18.04) 7.3.0")
Build machine cpu family: x86_64
Build machine cpu: x86_64
Library numa found: YES
Has header "numaif.h": YES
Library bsd found: NO
Checking for size of "void *": 8
Compiler for C supports argument -Wsign-compare: YES
Compiler for C supports argument -Wcast-qual: YES
Compiler for C supports argument -Wno-address-of-packed-member: YES
Fetching value of define "__SSE4_2__": 1
Fetching value of define "__AES__": 1
Fetching value of define "__PCLMUL__": 1
Fetching value of define "__AVX__": 1
Fetching value of define "__AVX2__": 1
Fetching value of define "__AVX512F__":
Compiler for C supports argument -Wno-format-truncation: YES
Checking for size of "void *": 8
Has header "linux/userfaultfd.h": YES
Checking for size of "void *": 8
Library elf found: NO
Library jansson found: NO
Program gen-pmdinfo-cfile.sh found: YES (/home/cburdick/dpdk/buildtools/gen-pmdinfo-cfile.sh)
Compiler for C supports argument -Wno-format-truncation: YES
Library libmusdk found: NO
Compiler for C supports argument -Wno-cast-qual: YES
Compiler for C supports argument -Wno-pointer-to-int-cast: YES
Library z found: NO
Compiler for C supports argument -Wno-uninitialized: YES
Compiler for C supports argument -Wno-unused-parameter: YES
Compiler for C supports argument -Wno-unused-variable: YES
Compiler for C supports argument -Wno-misleading-indentation: YES
Compiler for C supports argument -Wno-implicit-fallthrough: YES
Checking for size of "void *": 8
Compiler for C supports argument -Wno-unused-parameter: YES
Compiler for C supports argument -Wno-unused-value: YES
Compiler for C supports argument -Wno-strict-aliasing: YES
Compiler for C supports argument -Wno-format-extra-args: YES
Compiler for C supports argument -Wno-unused-variable: YES
Compiler for C supports argument -Wno-missing-field-initializers: YES
Compiler for C supports argument -Wno-sign-compare: YES
Compiler for C supports argument -Wno-unused-value: YES
Compiler for C supports argument -Wno-format: YES
Compiler for C supports argument -Wno-error=format-security: YES
Compiler for C supports argument -Wno-strict-aliasing: YES
Compiler for C supports argument -Wno-unused-but-set-variable: YES
Compiler for C supports argument -Wno-unused-value: YES
Compiler for C supports argument -Wno-unused-but-set-variable: YES
Library mnl found: YES
Library mlx4 found: YES
Library ibverbs found: YES
Compiler for C supports argument -Wextra: YES
Compiler for C supports argument -std=c11: YES
Compiler for C supports argument -Wno-strict-prototypes: YES
Compiler for C supports argument -D_BSD_SOURCE: YES
Compiler for C supports argument -D_DEFAULT_SOURCE: YES
Compiler for C supports argument -D_XOPEN_SOURCE=600: YES
Checking whether type "struct mlx4_wqe_lso_seg" has member "mss_hdr_size": YES
Configuring mlx4_autoconf.h using configuration
Library mnl found: YES
Library mlx5 found: YES
Library ibverbs found: YES
Compiler for C supports argument -Wextra: YES
Compiler for C supports argument -std=c11: YES
Compiler for C supports argument -Wno-strict-prototypes: YES
Compiler for C supports argument -D_BSD_SOURCE: YES
Compiler for C supports argument -D_DEFAULT_SOURCE: YES
Compiler for C supports argument -D_XOPEN_SOURCE=600: YES
Header <infiniband/mlx5dv.h> has symbol "MLX5DV_CQE_RES_FORMAT_CSUM_STRIDX": YES
Header <infiniband/mlx5dv.h> has symbol "MLX5DV_CONTEXT_MASK_TUNNEL_OFFLOADS": YES
Header <infiniband/mlx5dv.h> has symbol "MLX5DV_CONTEXT_FLAGS_MPW_ALLOWED": YES
Header <infiniband/mlx5dv.h> has symbol "MLX5DV_CONTEXT_FLAGS_CQE_128B_COMP": YES
Header <infiniband/mlx5dv.h> has symbol "MLX5DV_CQ_INIT_ATTR_FLAGS_CQE_PAD": YES
Header <infiniband/mlx5dv.h> has symbol "mlx5dv_create_flow_action_packet_reformat": NO
Header <infiniband/verbs.h> has symbol "IBV_FLOW_SPEC_MPLS": YES
Header <infiniband/verbs.h> has symbol "IBV_WQ_FLAG_RX_END_PADDING": NO
Header <linux/ethtool.h> has symbol "SUPPORTED_40000baseKR4_Full": YES
Header <linux/ethtool.h> has symbol "SUPPORTED_40000baseCR4_Full": YES
Header <linux/ethtool.h> has symbol "SUPPORTED_40000baseSR4_Full": YES
Header <linux/ethtool.h> has symbol "SUPPORTED_40000baseLR4_Full": YES
Header <linux/ethtool.h> has symbol "SUPPORTED_56000baseKR4_Full": YES
Header <linux/ethtool.h> has symbol "SUPPORTED_56000baseCR4_Full": YES
Header <linux/ethtool.h> has symbol "SUPPORTED_56000baseSR4_Full": YES
Header <linux/ethtool.h> has symbol "SUPPORTED_56000baseLR4_Full": YES
Header <linux/ethtool.h> has symbol "ETHTOOL_LINK_MODE_25000baseCR_Full_BIT": YES
Header <linux/ethtool.h> has symbol "ETHTOOL_LINK_MODE_50000baseCR2_Full_BIT": YES
Header <linux/ethtool.h> has symbol "ETHTOOL_LINK_MODE_100000baseKR4_Full_BIT": YES
Header <linux/if_link.h> has symbol "IFLA_PHYS_SWITCH_ID": YES
Header <linux/if_link.h> has symbol "IFLA_PHYS_PORT_NAME": YES
Header <linux/if_link.h> has symbol "IFLA_VXLAN_COLLECT_METADATA": YES
Header <linux/rtnetlink.h> has symbol "TCA_CHAIN": YES
Header <linux/pkt_cls.h> has symbol "TCA_FLOWER_ACT": YES
Header <linux/pkt_cls.h> has symbol "TCA_FLOWER_FLAGS": YES
Header <linux/pkt_cls.h> has symbol "TCA_FLOWER_KEY_ETH_TYPE": YES
Header <linux/pkt_cls.h> has symbol "TCA_FLOWER_KEY_ETH_DST": YES
Header <linux/pkt_cls.h> has symbol "TCA_FLOWER_KEY_ETH_DST_MASK": YES
Header <linux/pkt_cls.h> has symbol "TCA_FLOWER_KEY_ETH_SRC": YES
Header <linux/pkt_cls.h> has symbol "TCA_FLOWER_KEY_ETH_SRC_MASK": YES
Header <linux/pkt_cls.h> has symbol "TCA_FLOWER_KEY_IP_PROTO": YES
Header <linux/pkt_cls.h> has symbol "TCA_FLOWER_KEY_IPV4_SRC": YES
Header <linux/pkt_cls.h> has symbol "TCA_FLOWER_KEY_IPV4_SRC_MASK": YES
Header <linux/pkt_cls.h> has symbol "TCA_FLOWER_KEY_IPV4_DST": YES
Header <linux/pkt_cls.h> has symbol "TCA_FLOWER_KEY_IPV4_DST_MASK": YES
Header <linux/pkt_cls.h> has symbol "TCA_FLOWER_KEY_IPV6_SRC": YES
Header <linux/pkt_cls.h> has symbol "TCA_FLOWER_KEY_IPV6_SRC_MASK": YES
Header <linux/pkt_cls.h> has symbol "TCA_FLOWER_KEY_IPV6_DST": YES
Header <linux/pkt_cls.h> has symbol "TCA_FLOWER_KEY_IPV6_DST_MASK": YES
Header <linux/pkt_cls.h> has symbol "TCA_FLOWER_KEY_TCP_SRC": YES
Header <linux/pkt_cls.h> has symbol "TCA_FLOWER_KEY_TCP_SRC_MASK": YES
Header <linux/pkt_cls.h> has symbol "TCA_FLOWER_KEY_TCP_DST": YES
Header <linux/pkt_cls.h> has symbol "TCA_FLOWER_KEY_TCP_DST_MASK": YES
Header <linux/pkt_cls.h> has symbol "TCA_FLOWER_KEY_UDP_SRC": YES
Header <linux/pkt_cls.h> has symbol "TCA_FLOWER_KEY_UDP_SRC_MASK": YES
Header <linux/pkt_cls.h> has symbol "TCA_FLOWER_KEY_UDP_DST": YES
Header <linux/pkt_cls.h> has symbol "TCA_FLOWER_KEY_UDP_DST_MASK": YES
Header <linux/pkt_cls.h> has symbol "TCA_FLOWER_KEY_VLAN_ID": YES
Header <linux/pkt_cls.h> has symbol "TCA_FLOWER_KEY_VLAN_PRIO": YES
Header <linux/pkt_cls.h> has symbol "TCA_FLOWER_KEY_VLAN_ETH_TYPE": YES
Header <linux/pkt_cls.h> has symbol "TCA_FLOWER_KEY_TCP_FLAGS": YES
Header <linux/pkt_cls.h> has symbol "TCA_FLOWER_KEY_TCP_FLAGS_MASK": YES
Header <linux/pkt_cls.h> has symbol "TC_ACT_GOTO_CHAIN": YES
Header <linux/tc_act/tc_vlan.h> has symbol "TCA_VLAN_PUSH_VLAN_PRIORITY": YES
Header <linux/pkt_cls.h> has symbol "TCA_FLOWER_KEY_ENC_KEY_ID": YES
Header <linux/pkt_cls.h> has symbol "TCA_FLOWER_KEY_ENC_IPV4_SRC": YES
Header <linux/pkt_cls.h> has symbol "TCA_FLOWER_KEY_ENC_IPV4_SRC_MASK": YES
Header <linux/pkt_cls.h> has symbol "TCA_FLOWER_KEY_ENC_IPV4_DST": YES
Header <linux/pkt_cls.h> has symbol "TCA_FLOWER_KEY_ENC_IPV4_DST_MASK": YES
Header <linux/pkt_cls.h> has symbol "TCA_FLOWER_KEY_ENC_IPV6_SRC": YES
Header <linux/pkt_cls.h> has symbol "TCA_FLOWER_KEY_ENC_IPV6_SRC_MASK": YES
Header <linux/pkt_cls.h> has symbol "TCA_FLOWER_KEY_ENC_IPV6_DST": YES
Header <linux/pkt_cls.h> has symbol "TCA_FLOWER_KEY_ENC_IPV6_DST_MASK": YES
Header <linux/pkt_cls.h> has symbol "TCA_FLOWER_KEY_ENC_UDP_SRC_PORT": YES
Header <linux/pkt_cls.h> has symbol "TCA_FLOWER_KEY_ENC_UDP_SRC_PORT_MASK": YES
Header <linux/pkt_cls.h> has symbol "TCA_FLOWER_KEY_ENC_UDP_DST_PORT": YES
Header <linux/pkt_cls.h> has symbol "TCA_FLOWER_KEY_ENC_UDP_DST_PORT_MASK": YES
Header <linux/tc_act/tc_tunnel_key.h> has symbol "TCA_ACT_TUNNEL_KEY": YES
Header <linux/tc_act/tc_tunnel_key.h> has symbol "TCA_TUNNEL_KEY_ENC_DST_PORT": YES
Header <linux/tc_act/tc_tunnel_key.h> has symbol "TCA_TUNNEL_KEY_NO_CSUM": YES
Header <linux/tc_act/tc_pedit.h> has symbol "TCA_PEDIT_KEY_EX_HDR_TYPE_UDP": YES
Header <rdma/rdma_netlink.h> has symbol "RDMA_NL_NLDEV": YES
Header <rdma/rdma_netlink.h> has symbol "RDMA_NLDEV_CMD_GET": YES
Header <rdma/rdma_netlink.h> has symbol "RDMA_NLDEV_CMD_PORT_GET": YES
Header <rdma/rdma_netlink.h> has symbol "RDMA_NLDEV_ATTR_DEV_INDEX": YES
Header <rdma/rdma_netlink.h> has symbol "RDMA_NLDEV_ATTR_DEV_NAME": YES
Header <rdma/rdma_netlink.h> has symbol "RDMA_NLDEV_ATTR_PORT_INDEX": YES
Header <rdma/rdma_netlink.h> has symbol "RDMA_NLDEV_ATTR_NDEV_INDEX": NO
Checking whether type "struct mlx5dv_sw_parsing_caps" has member "sw_parsing_offloads": YES
Checking whether type "struct ibv_counter_set_init_attr" has member "counter_set_id": YES
Checking whether type "struct ibv_counters_init_attr" has member "comp_mask": NO
Configuring mlx5_autoconf.h using configuration
Library libmusdk found: NO
Library libmusdk found: NO
Library pcap found: NO
Compiler for C supports argument -Wno-unused-parameter: YES
Compiler for C supports argument -Wno-sign-compare: YES
Compiler for C supports argument -Wno-missing-prototypes: YES
Compiler for C supports argument -Wno-cast-qual: YES
Compiler for C supports argument -Wno-unused-function: YES
Compiler for C supports argument -Wno-unused-variable: YES
Compiler for C supports argument -Wno-strict-aliasing: YES
Compiler for C supports argument -Wno-missing-prototypes: YES
Compiler for C supports argument -Wno-unused-value: YES
Compiler for C supports argument -Wno-format-nonliteral: YES
Compiler for C supports argument -Wno-shift-negative-value: YES
Compiler for C supports argument -Wno-unused-but-set-variable: YES
Compiler for C supports argument -Wno-missing-declarations: YES
Compiler for C supports argument -Wno-maybe-uninitialized: YES
Compiler for C supports argument -Wno-strict-prototypes: YES
Compiler for C supports argument -Wno-shift-negative-value: YES
Compiler for C supports argument -Wno-implicit-fallthrough: YES
Compiler for C supports argument -Wno-format-extra-args: YES
Compiler for C supports argument -Wno-visibility: YES
Compiler for C supports argument -Wno-empty-body: YES
Compiler for C supports argument -Wno-invalid-source-encoding: YES
Compiler for C supports argument -Wno-sometimes-uninitialized: YES
Compiler for C supports argument -Wno-pointer-bool-conversion: YES
Checking for size of "void *": 8
Compiler for C supports argument -Wno-strict-aliasing: YES
Compiler for C supports argument -Wextra: YES
Compiler for C supports argument -Wdisabled-optimization: YES
Compiler for C supports argument -Waggregate-return: YES
Compiler for C supports argument -Wnested-externs: YES
Compiler for C supports argument -Wbad-function-cast: YES
Compiler for C supports argument -Wno-sign-compare: YES
Compiler for C supports argument -Wno-unused-parameter: YES
Compiler for C supports argument -Wno-unused-variable: YES
Compiler for C supports argument -Wno-empty-body: YES
Compiler for C supports argument -Wno-unused-but-set-variable: YES
Library sze2 found: NO
Header <linux/pkt_cls.h> has symbol "TCA_FLOWER_UNSPEC": YES
Header <linux/pkt_cls.h> has symbol "TCA_FLOWER_KEY_VLAN_PRIO": YES
Header <linux/pkt_cls.h> has symbol "TCA_BPF_UNSPEC": YES
Header <linux/pkt_cls.h> has symbol "TCA_BPF_FD": YES
Header <linux/tc_act/tc_bpf.h> has symbol "TCA_ACT_BPF_UNSPEC": YES
Header <linux/tc_act/tc_bpf.h> has symbol "TCA_ACT_BPF_FD": YES
Configuring tap_autoconf.h using configuration
Compiler for C supports argument -fno-prefetch-loop-arrays: YES
Compiler for C supports argument -Wno-maybe-uninitialized: YES
Compiler for C supports argument -Wall: YES
Compiler for C supports argument -Wextra: YES
Compiler for C supports argument -D_BSD_SOURCE: YES
Compiler for C supports argument -D_DEFAULT_SOURCE: YES
Compiler for C supports argument -D_XOPEN_SOURCE=600: YES
Compiler for C supports argument -Wno-unused-parameter: YES
Compiler for C supports argument -Wno-unused-value: YES
Compiler for C supports argument -Wno-strict-aliasing: YES
Compiler for C supports argument -Wno-format-extra-args: YES
Library IPSec_MB found: NO
Library IPSec_MB found: NO
Found pkg-config: /usr/bin/pkg-config (0.29.1)
Native dependency libcrypto found: YES 1.1.0g
Library libsso_kasumi found: NO
Library libmusdk found: NO
Dependency libcrypto found: YES (cached)
Dependency libcrypto found: YES (cached)
Library libsso_zuc found: NO
Dependency libisal found: NO
Dependency zlib found: NO
Compiler for C supports argument -Wno-sign-compare: YES
Compiler for C supports argument -Wno-unused-value: YES
Compiler for C supports argument -Wno-format: YES
Compiler for C supports argument -Wno-error=format-security: YES
Compiler for C supports argument -Wno-strict-aliasing: YES
Compiler for C supports argument -Wno-unused-but-set-variable: YES
Library execinfo found: NO
Compiler for C supports argument -Wno-format-truncation: YES
Dependency zlib found: NO
Library execinfo found: NO
Program doxygen found: NO
Program sphinx-build found: NO
kernel/linux/kni/meson.build:16: WARNING: Passed invalid keyword argument "console".
WARNING: This will become a hard error in the future.
WARNING: Unknown keyword arguments in target rte_kni: console
Configuring rte_build_config.h using configuration
Program buildtools/symlink-drivers-solibs.sh found: YES (/bin/sh /home/cburdick/dpdk/buildtools/symlink-drivers-solibs.sh)
Message:
=================
Libraries Enabled
=================

libs:
\tcompat, cmdline, kvargs, eal, ring, mempool, mbuf, net,
\tethdev, pci, metrics, hash, timer, acl, bbdev, bitratestats,
\tcfgfile, compressdev, cryptodev, distributor, efd, eventdev, gro, gso,
\tip_frag, jobstats, kni, latencystats, lpm, member, meter, power,
\tpdump, rawdev, reorder, sched, security, vhost, port, table,
\tpipeline, flow_classify, bpf,

Build targets in project: 411
Found ninja-1.8.2 at /usr/bin/ninja
[cburdick@dev01 ~/dpdk] (master)
$ cd build
[cburdick@dev01 ~/dpdk/build] (master)
$ ninja
[1428/1431] Generating igb_uio with a custom command.
make: Entering directory '/usr/src/linux-headers-4.15.0-20-generic'
Makefile:976: "Cannot use CONFIG_STACK_VALIDATION=y, please install libelf-dev, libelf-devel or elfutils-libelf-devel"
  CC [M]  /home/cburdick/dpdk/build/kernel/linux/igb_uio/igb_uio.o
  Building modules, stage 2.
  MODPOST 1 modules
  CC      /home/cburdick/dpdk/build/kernel/linux/igb_uio/igb_uio.mod.o
  LD [M]  /home/cburdick/dpdk/build/kernel/linux/igb_uio/igb_uio.ko
make: Leaving directory '/usr/src/linux-headers-4.15.0-20-generic'
[1431/1431] Generating rte_kni with a custom command.
make: Entering directory '/usr/src/linux-headers-4.15.0-20-generic'
Makefile:976: "Cannot use CONFIG_STACK_VALIDATION=y, please install libelf-dev, libelf-devel or elfutils-libelf-devel"
  CC [M]  /home/cburdick/dpdk/build/kernel/linux/kni/kni_net.o
  CC [M]  /home/cburdick/dpdk/build/kernel/linux/kni/kni_misc.o
  CC [M]  /home/cburdick/dpdk/build/kernel/linux/kni/kni_ethtool.o
  CC [M]  /home/cburdick/dpdk/build/kernel/linux/kni/ethtool/ixgbe/ixgbe_ethtool.o
  CC [M]  /home/cburdick/dpdk/build/kernel/linux/kni/ethtool/ixgbe/ixgbe_82599.o
  CC [M]  /home/cburdick/dpdk/build/kernel/linux/kni/ethtool/ixgbe/ixgbe_api.o
  CC [M]  /home/cburdick/dpdk/build/kernel/linux/kni/ethtool/ixgbe/ixgbe_x540.o
  CC [M]  /home/cburdick/dpdk/build/kernel/linux/kni/ethtool/ixgbe/ixgbe_common.o
  CC [M]  /home/cburdick/dpdk/build/kernel/linux/kni/ethtool/ixgbe/ixgbe_phy.o
  CC [M]  /home/cburdick/dpdk/build/kernel/linux/kni/ethtool/ixgbe/ixgbe_82598.o
  CC [M]  /home/cburdick/dpdk/build/kernel/linux/kni/ethtool/ixgbe/ixgbe_main.o
  CC [M]  /home/cburdick/dpdk/build/kernel/linux/kni/ethtool/ixgbe/kcompat.o
  CC [M]  /home/cburdick/dpdk/build/kernel/linux/kni/ethtool/igb/e1000_82575.o
  CC [M]  /home/cburdick/dpdk/build/kernel/linux/kni/ethtool/igb/e1000_i210.o
  CC [M]  /home/cburdick/dpdk/build/kernel/linux/kni/ethtool/igb/e1000_mbx.o
  CC [M]  /home/cburdick/dpdk/build/kernel/linux/kni/ethtool/igb/e1000_api.o
  CC [M]  /home/cburdick/dpdk/build/kernel/linux/kni/ethtool/igb/igb_main.o
  CC [M]  /home/cburdick/dpdk/build/kernel/linux/kni/ethtool/igb/igb_vmdq.o
  CC [M]  /home/cburdick/dpdk/build/kernel/linux/kni/ethtool/igb/e1000_manage.o
  CC [M]  /home/cburdick/dpdk/build/kernel/linux/kni/ethtool/igb/igb_ethtool.o
  CC [M]  /home/cburdick/dpdk/build/kernel/linux/kni/ethtool/igb/igb_param.o
  CC [M]  /home/cburdick/dpdk/build/kernel/linux/kni/ethtool/igb/e1000_mac.o
  CC [M]  /home/cburdick/dpdk/build/kernel/linux/kni/ethtool/igb/e1000_phy.o
  CC [M]  /home/cburdick/dpdk/build/kernel/linux/kni/ethtool/igb/e1000_nvm.o
  LD [M]  /home/cburdick/dpdk/build/kernel/linux/kni/rte_kni.o
  Building modules, stage 2.
  MODPOST 1 modules
  CC      /home/cburdick/dpdk/build/kernel/linux/kni/rte_kni.mod.o
  LD [M]  /home/cburdick/dpdk/build/kernel/linux/kni/rte_kni.ko
make: Leaving directory '/usr/src/linux-headers-4.15.0-20-generic'
[cburdick@dev01 ~/dpdk/build] (master)
$ PKG_CONFIG_PATH=meson-private/ pkg-config --libs --static libdpdk|grep mlx
-L/usr/local/lib/x86_64-linux-gnu -lrte_flow_classify -lrte_eventdev -lrte_ip_frag -lrte_power -lrte_hash -lrte_pdump -lrte_pipeline -lrte_table -lrte_mbuf -lrte_bbdev -lrte_bpf -lrte_vhost -lrte_metrics -lrte_mempool -lrte_jobstats -lrte_reorder -lrte_net -lrte_security -lrte_eal -lrte_ring -lrte_ethdev -lrte_compressdev -lrte_rawdev -lrte_kvargs -lrte_pci -lrte_cfgfile -lrte_gro -lrte_gso -lrte_cryptodev -lrte_latencystats -lrte_sched -lrte_efd -lrte_distributor -lrte_acl -lrte_member -lrte_cmdline -lrte_lpm -lrte_meter -lrte_kni -lrte_bitratestats -lrte_timer -lrte_port -lrte_mempool_bucket -lrte_pmd_vdev_netvsc -lrte_pmd_ark -lrte_pmd_failsafe -lrte_pmd_netvsc -lrte_pmd_null_crypto -lrte_bus_ifpga -lrte_common_dpaax -lrte_pmd_ixgbe -lrte_mempool_ring -lrte_pmd_kni -lrte_pmd_vmxnet3 -lrte_pmd_mlx4 -lrte_pmd_virtio -Wl,--no-as-needed -lrte_mempool_dpaa -lrte_pmd_ena -lrte_bus_fslmc -lrte_pmd_avf -lrte_pmd_dpaa2_sec -lrte_common_octeontx -lrte_pmd_skeleton_rawdev -lrte_pmd_crypto_scheduler -lrte_pmd_dpaa2_qdma -lrte_pmd_vhost -ldl -lrte_bus_dpaa -lrte_pmd_fm10k -lrte_pmd_bnxt -lrte_pmd_qat -lrte_pmd_bond -lrte_pmd_axgbe -lrte_pmd_dpaa2 -lrte_pmd_skeleton_event -lrte_pmd_dpaa_event -lrte_mempool_stack -pthread -lrte_pmd_ccp -lrte_pmd_octeontx_compress -lrte_pmd_sw_event -lrte_mempool_octeontx -Wl,-Bdynamic -lrte_pmd_dpaa_sec -lrte_pmd_atlantic -lrte_pmd_octeontx_event -lrte_pmd_avp -lrte_bus_pci -lrte_pmd_dpaa2_cmdif -lrte_pmd_mlx5 -lrte_pmd_opdl_event -lrte_pmd_tap -lrte_pmd_caam_jr -lrte_pmd_sfc -lcrypto -lrte_pmd_enetc -lrte_mempool_dpaa2 -lrte_pmd_dpaa2_event -lrte_pmd_ifc -lrte_pmd_liquidio -lrte_pmd_cxgbe -lm -lrte_pmd_enic -lrte_bus_vdev -lrte_pmd_e1000 -lrte_pmd_softnic -lrte_pmd_ifpga_rawdev -lrte_bus_vmbus -lrte_pmd_octeontx_crypto -lrte_pmd_null -lnuma -lrte_common_cpt -lrte_pmd_nfp -lrte_pmd_qede -lrte_pmd_i40e -lrte_pmd_dpaa -Wl,--whole-archive -lrte_pmd_bbdev_null -lrte_pmd_af_packet -lrte_pmd_thunderx -lrte_pmd_openssl -lrte_pmd_octeontx -lrte_pmd_dsw_event -Wl,--no-whole-archive -lrte_pmd_ring -lrte_pmd_virtio_crypto

Re: [dpdk-dev] [PATCH 1/1] eal: Don't fail secondary if primary is missing tailqs

[Richardson, Bruce]

> -----Original Message-----
> From: Burdick, Cliff [mailto:Cliff.Burdick@viasat.com]
> Sent: Thursday, November 15, 2018 4:55 PM
> To: Richardson, Bruce <bruce.richardson@intel.com>
> Cc: Luca Boccassi <bluca@debian.org>; Thomas Monjalon
> <thomas@monjalon.net>; Burakov, Anatoly <anatoly.burakov@intel.com>;
> dev@dpdk.org
> Subject: RE: [dpdk-dev] [PATCH 1/1] eal: Don't fail secondary if primary
> is missing tailqs
> 
> 
> 
> -----Original Message-----
> From: Bruce Richardson [mailto:bruce.richardson@intel.com]
> Sent: Thursday, November 15, 2018 8:41 AM
> To: Burdick, Cliff
> Cc: Luca Boccassi; Thomas Monjalon; Burakov, Anatoly; dev@dpdk.org
> Subject: Re: [dpdk-dev] [PATCH 1/1] eal: Don't fail secondary if primary
> is missing tailqs
> 
> > On Thu, Nov 15, 2018 at 04:15:36PM +0000, Burdick, Cliff wrote:
> > >
> > >
> > > -----Original Message-----
> > > From: Luca Boccassi [mailto:bluca@debian.org]
> > > Sent: Thursday, November 15, 2018 1:33 AM
> > > To: Burdick, Cliff; Bruce Richardson
> > > Cc: Thomas Monjalon; Burakov, Anatoly; dev@dpdk.org
> > > Subject: Re: [dpdk-dev] [PATCH 1/1] eal: Don't fail secondary if
> > > primary is missing tailqs
> > >
> > > > On Wed, 2018-11-14 at 18:24 +0000, Burdick, Cliff wrote:
> > > > >
> > > > > -----Original Message-----
> > > > > From: Luca Boccassi [mailto:bluca@debian.org]
> > > > > Sent: Wednesday, November 14, 2018 10:15 AM
> > > > > To: Burdick, Cliff; Bruce Richardson
> > > > > Cc: Thomas Monjalon; Burakov, Anatoly; dev@dpdk.org
> > > > > Subject: Re: [dpdk-dev] [PATCH 1/1] eal: Don't fail secondary if
> > > > > primary is missing tailqs
> > > > >
> > > > > > On Wed, 2018-11-14 at 17:40 +0000, Burdick, Cliff wrote:
> > > > > > >
> > > > > > > -----Original Message-----
> > > > > > > From: Bruce Richardson [mailto:bruce.richardson@intel.com]
> > > > > > > Sent: Wednesday, November 14, 2018 3:48 AM
> > > > > > > To: Burdick, Cliff
> > > > > > > Cc: Thomas Monjalon; Burakov, Anatoly; dev@dpdk.org
> > > > > > > Subject: Re: [dpdk-dev] [PATCH 1/1] eal: Don't fail secondary
> > > > > > > if primary is missing tailqs
> > > > > > >
> > > > > > > On Tue, Nov 13, 2018 at 11:42:51PM +0000, Burdick, Cliff
> wrote:
> > > > > > > > >
> > > > > > > > > ________________________________________
> > > > > > > > > From: Thomas Monjalon [thomas@monjalon.net]
> > > > > > > > > Sent: Tuesday, November 13, 2018 2:18 PM
> > > > > > > > > To: Burdick, Cliff
> > > > > > > > > Cc: Burakov, Anatoly; dev@dpdk.org;
> > > > > > > > > bruce.richardson@intel.co m
> > > > > > > > > Subject: Re: [dpdk-dev] [PATCH 1/1] eal: Don't fail
> > > > > > > > > secondary if primary is missing tailqs
> > > > > > > > >
> > > > > > > > > 13/11/2018 23:08, Burdick, Cliff:
> > > > > > > > > > From: Thomas Monjalon [mailto:thomas@monjalon.net]
> > > > > > > > > > > 13/11/2018 17:38, Burdick, Cliff:
> > > > > > > > > > > > From: Thomas Monjalon [mailto:thomas@monjalon.net]
> > > > > > > > > > > > 13/11/2018 16:45, Burdick, Cliff:
> > > > > > > > > > > > > From: Burakov, Anatoly
> [mailto:anatoly.burakov@intel.
> > > > > > > > > > > > > com]
> > > > > > > > > > > > > > On 13-Nov-18 9:21 AM, Thomas Monjalon wrote:
> > > > > > > > > > > > > > > 13/11/2018 00:33, Burdick, Cliff:
> > > > > > > > > > > > > > > > This patch was submitted by Jean Tourrilhes
> > > > > > > > > > > > > > > > over two years ago, but didn't receive any
> responses.
> > > > > > > > > > > > > > > > I hit the same issue recently when trying to
> > > > > > > > > > > > > > > > use cgo
> > > > > > > > > > > > > > > > (Golang) as a primary process linked to
> > > > > > > > > > > > > > > > libdpdk.a against a C++ application linked
> > > > > > > > > > > > > > > > against the same library.> > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > The question is to know why you don't have the
> > > > > > > > > > > > > > > same constructors in primary and seconday?
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > I've hit similar things in the past. I believe
> > > > > > > > > > > > > > it was caused by our build system stripping out
> > > > > > > > > > > > > > unused libraries (such as
> > > > > > > > > > > > > > rte_hash) from the binary and thus not calling
> > > > > > > > > > > > > > the constructor in the primary, but doing so in
> > > > > > > > > > > > > > the secondary (or something to that effect). In
> > > > > > > > > > > > > > any case, this is caused by linking different
> > > > > > > > > > > > > > number of libraries to primary and secondary,
> > > > > > > > > > > > > > and should probably be fixed in the build
> > > > > > > > > > > > > > system, not in the tailqs code (unless we
> > > > > > > > > > > > > > specifically support having different linked
> > > > > > > > > > > > > > libraries to primary and secondary?).> > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > > Right, I think the original author of the patch
> > > > > > > > > > > > > stated the reasons in the link I provided. The
> > > > > > > > > > > > > build system seems like the most appropriate place
> > > > > > > > > > > > > to fix it, but the patch got me going quickly. I
> > > > > > > > > > > > > think the question is whether you want DPDK to
> > > > > > > > > > > > > support these other ways of linking.
> > > > > > > > > > > > > I'm
> > > > > > > > > > > > > certainly not the first to use cgo, since there's
> > > > > > > > > > > > > a virtual switch project doing the same:
> > > > > > > > > > > > >
> > > > > > > > > > > > > https://urldefense.proofpoint.com/v2/url?u=https-3
> > > > > > > > > > > > > A__
> > > > > > > > > > > > > gith
> > > > > > > > > > > > > ub.co
> > > > > > > > > > > > > m_lago
> > > > > > > > > > > > > pu
> > > > > > > > > > > > > s_vsw&d=DwICAg&c=jcv3orpCsv7C4ly8-
> > > > > > > > > > > > > ubDoUfrxF5xIGWmptxGWP5vi5w&r =m1RLQ OG
> > > > > > > > > > > > > Okz9MauvVLZmiGtyWc5mA7DejbPFNE1IDj-
> > > > > > > > > > > > > 4&m=hQqVCNwW7eoEzB_hLFK97i8 idS8FI qX
> > > > > > > > > > > > > oPeclwsIZq7Y&s=BMoBlwkqljwWIBY3SE3pPMCfVnOUlDuZLrn
> > > > > > > > > > > > > o4-
> > > > > > > > > > > > > SojKM&e=
> > > > > > > > > > > > >
> > > > > > > > > > > > > They don't use primary/secondary processes,
> > > > > > > > > > > > > though, so the issue is  never hit. I'm in a
> > > > > > > > > > > > > situation where using cgo seemed like the easiest
> > > > > > > > > > > > > path to accomplish what I'm doing since I needed
> > > > > > > > > > > > > specialized  libraries for it that were not
> > > > > > > > > > > > > available in C/C++. At some point I  bet someone
> > > > > > > > > > > > > would use Cython to start linking against DPDK as
> > > > > > > > > > > > > well,  and we'd likely run into the same issue.> >
> > > > > > > > > > > > > > > For sure, we want to support using DPDK with
> cgo or cython.
> > > > > > > > > > > > > But it is not clear what is the relation with not
> > > > > > > > > > > > > having the same compilation for primary and
> secondary.
> > > > > > > > > > > > > Please
> > > > > > > > > > > > > could you elaborate?> > >
> > > > > > > > > > > >
> > > > > > > > > > > > Hi Thomas, I think Jean explained it well here:
> > > > > > > > > > > > https://urldefense.proofpoint.com/v2/url?u=https-3A_
> > > > > > > > > > > > _de
> > > > > > > > > > > > v.dp
> > > > > > > > > > > > dk.narkive.
> > > > > > > > > > > > com_ZM3a7QD1_dpdk-2Ddev-2Dbug-2Dstatic-2Dconstructor
> > > > > > > > > > > > s-
> > > > > > > > > > > > 2Dconsider
> > > > > > > > > > > > ed-2De
> > > > > > > > > > > > vil&d=DwICAg&c=jcv3orpCsv7C4ly8-
> > > > > > > > > > > > ubDoUfrxF5xIGWmptxGWP5vi5w&r=m1R LQOGOk
> > > > > > > > > > > > z9MauvVLZmiGtyWc5mA7DejbPFNE1IDj-
> > > > > > > > > > > > 4&m=C69wDgrjDX8_oXp1M_3bnmWOOZd GqwBBG
> > > > > > > > > > > > 9vzkyGDWGQ&s=YYn2N7WrzJpH1ptNrLZad0nPAQdrUyqBckk2uFu
> > > > > > > > > > > > WYP
> > > > > > > > > > > > Q&e=
> > > > > > > > > > > >
> > > > > > > > > > > > "The build system of the application does not have
> > > > > > > > > > > > all the subtelties of the DPDK build system, and
> > > > > > > > > > > > ends up including
> > > > > > > > > > > > *all*
> > > > > > > > > > > > the constructors, wether they are used or not in the
> > > > > > > > > > > > code.
> > > > > > > > > > > > Moreover, they are included in a different order.
> > > > > > > > > > > > Actually,
> > > > > > > > > > > > by default the builds include no constructors at all
> > > > > > > > > > > > (which is a big fail), so the library needs to be
> > > > > > > > > > > > included with --whole-archive (see Snort DPDK
> > > > > > > > > > > > instructions)."
> > > > > > > > > > > >
> > > > > > > > > > > > I will get to the bottom of my exact case to
> > > > > > > > > > > > understand what's happening, but my primary
> > > > > > > > > > > > application is a cgo application that I'm linking to
> > > > > > > > > > > > by using almost exactly the same flags that are used
> > > > > > > > > > > > in the DPDK build system to build examples. The DPDK
> > > > > > > > > > > > libraries I'm linking against is a single location
> > > > > > > > > > > > for both primary and secondary; in other words, I
> don't build DPDK twice.
> > > > > > > > > > > >
> > > > > > > > > > > > OK I understand, thanks.
> > > > > > > > > > > >
> > > > > > > > > > > > You had alluded to a pkg-config for DPDK in the 2015
> > > > > > > > > > > > thread, which cgo can use, but I don't know if that
> > > > > > > > > > > > ever was implemented. Cgo can use pkg-config if it's
> > > > > > > > > > > > available, otherwise the only tools are specifying
> > > > > > > > > > > > LDFLAGS and CFLAGS into their build system.
> > > > > > > > > > >
> > > > > > > > > > > Yes, the right answer is still pkg-config :) The good
> > > > > > > > > > > news is that it is now implemented thanks to the meson
> > > > > > > > > > > build
> > > > > > > > > > > system:
> > > > > > > > > > >
> > > > > > > > > > > https://urldefense.proofpoint.com/v2/url?u=http-3A__gi
> > > > > > > > > > > t.d
> > > > > > > > > > > pdk.
> > > > > > > > > > > org_dp
> > > > > > > > > > > dk_tree_doc_build-2Dsdk-2Dmeson.txt-
> > > > > > > > > > > 23n182&d=DwICAg&c=jcv3orpCsv7C4
> > > > > > > > > > > ly8-
> > > > > > > > > > > ubDoUfrxF5xIGWmptxGWP5vi5w&r=m1RLQOGOkz9MauvVLZmiGtyWc
> > > > > > > > > > > 5mA
> > > > > > > > > > > 7Dej
> > > > > > > > > > > bP
> > > > > > > > > > > FNE1IDj-
> > > > > > > > > > > > 4&m=C69wDgrjDX8_oXp1M_3bnmWOOZdGqwBBG9vzkyGDWGQ&s=oC
> > > > > > > > > > > > 86K
> > > > > > > > > > > > D_R
> > > > > > > > > > >
> > > > > > > > > > > J1T6rfzi3x5zFT1Ri13ELpKmsyFqpgDbgFg&e=
> > > > > > > > > >
> > > > > > > > > > Hi Thomas, are there instructions on how to use
> > > > > > > > > > pkg-config to build the mlx4/5 PMD? I noticed a patch
> > > > > > > > > > was submitted in September to add support for it, but
> > > > > > > > > > that link you provided on using meson doesn't say how to
> > > > > > > > > > build specific drivers. It appears to be disabled by
> default.
> > > > > > > > > > If the dependency is found, meson will enable the PMD
> > > > > > > > > > when building DPDK.
> > > > > > > > >
> > > > > > > > > Do you know where exactly that is? I've been using mlx5
> > > > > > > > > for a while on this system, and I can see that 18.11-rc2
> > > > > > > > > meson
> > > > > > > > > build+ninja built the pmd, but it's not on the --libs
> > > > > > > > > build+listing
> > > > > > > > > for
> > > > > > > > > pkg-config. Does it tell me what I was missing?
> > > > > > > > >
> > > > > > > >
> > > > > > > > For dynamic linking of applications, the drivers are not
> > > > > > > > normally linked in. Instead, they should be loaded from the
> > > > > > > > drivers directory as .so files
> > > > > > > > - normally by default in EAL as the driver .so's should be
> > > > > > > > copied to the EAL_PMD_PATH where EAL finds them
> automatically.
> > > > > > > > [This applies to both meson and make builds, though only
> > > > > > > > meson generates the .pc file for pkg-config]
> > > > > > > >
> > > > > > > > If you are doing a static build, then you need to explicitly
> > > > > > > > link in the drivers. You can get a list from pkg-config
> > > > > > > > using the "
> > > > > > > > --static" flag in this case. A good example of how to use
> > > > > > > > pkg- config in this way can be found in the Makefiles for
> > > > > > > > most examples, e.g. examples/helloworld/Makefile, reproduced
> below.
> > > > > > > >
> > > > > > > > Regards,
> > > > > > > > /Bruce
> > > > > > > >
> > > > > > > > all: shared
> > > > > > > > .PHONY: shared static
> > > > > > > > shared: build/$(APP)-shared
> > > > > > > >         ln -sf $(APP)-shared build/$(APP)
> > > > > > > > static: build/$(APP)-static
> > > > > > > >         ln -sf $(APP)-static build/$(APP)
> > > > > > > >
> > > > > > > > PC_FILE := $(shell pkg-config --path libdpdk) CFLAGS += -O3
> > > > > > > > $(shell pkg-config --cflags libdpdk) LDFLAGS_SHARED =
> > > > > > > > $(shell
> > > > > > > > pkg- config -- libs libdpdk) LDFLAGS_STATIC = -Wl,-Bstatic
> > > > > > > > $(shell pkg-config
> > > > > > > > --
> > > > > > > > static --libs libdpdk)
> > > > > > > >
> > > > > > > > build/$(APP)-shared: $(SRCS-y) Makefile $(PC_FILE) | build
> > > > > > > >         $(CC) $(CFLAGS) $(SRCS-y) -o $@ $(LDFLAGS)
> > > > > > > > $(LDFLAGS_SHARED)
> > > > > > > >
> > > > > > > > build/$(APP)-static: $(SRCS-y) Makefile $(PC_FILE) | build
> > > > > > > >         $(CC) $(CFLAGS) $(SRCS-y) -o $@ $(LDFLAGS)
> > > > > > > > $(LDFLAGS_STATIC)
> > > > > > > >
> > > > > > > > build:
> > > > > > > >         @mkdir -p $@
> > > > > > >
> > > > > > > Thanks Bruce. I tried getting this to compile using cgo, and
> > > > > > > it's causing more pain than it's worth. I used the --static
> > > > > > > --libs options, and there were still numerous linker errors,
> > > > > > > some specific to mlx, and some not. Specifically libmlx5 and
> > > > > > > libmnl are both needed, but they're not part of the linker
> > > > > > > line from pkg-config. At this point I'll just break the Go
> > > > > > > application up into a separate C application that handles all
> > > > > > > the DPDK parts, and send messages between them.
> > > > > >
> > > > > > Hi,
> > > > > >
> > > > > > As far as I can see, both mnl and mlx5 (and all the other
> > > > > > reverse
> > > > > > dependencies) are listed correctly in the libdpdk.pc
> > > > > > Libs.private entry, and pkg-config --libs --static libdpdk.pc
> > > > > > does print them as intended. This is with 18.11-rc3.
> > > > > > Are you sure everything is correct (pkg-config path is right, --
> > > > > > static is used, etc)?
> > > > > >
> > > > > > --
> > > > > > Kind regards,
> > > > > > Luca Boccassi
> > > > >
> > > > > Hi Luca, here is what pkg-config gives:
> > > > >
> > > > > PKG_CONFIG_PATH=meson-private/ pkg-config --libs --static libdpdk
> > > > > -L/usr/local/lib/x86_64-linux-gnu -lrte_eventdev -lrte_power
> > > > > -lrte_ip_frag -lrte_hash -lrte_pdump -lrte_eal -lrte_pipeline
> > > > > -lrte_table -lrte_bbdev -lrte_bpf -lrte_vhost -lrte_metrics
> > > > > -lrte_jobstats -lrte_net -lrte_reorder -lrte_ring -lrte_mempool
> > > > > -lrte_security -lrte_compressdev -lrte_rawdev -lrte_mbuf
> > > > > -lrte_kvargs -lrte_port -lrte_pci -lrte_ethdev -lrte_gro -lrte_gso
> > > > > -lrte_cryptodev -lrte_sched -lrte_latencystats -lrte_efd
> > > > > -lrte_distributor -lrte_meter -lrte_acl -lrte_member -lrte_cmdline
> > > > > -lrte_lpm -lrte_kni -lrte_cfgfile -lrte_bitratestats -lrte_timer
> > > > > -lrte_flow_classify -lrte_mempool_bucket -lrte_pmd_null_crypto
> > > > > -lrte_pmd_failsafe -lrte_bus_ifpga -lrte_pmd_atlantic
> > > > > -lrte_pmd_mlx4 -lrte_pmd_vmxnet3 -lrte_pmd_avp -lrte_common_dpaax
> > > > > -lrte_pmd_ena -lcrypto -lrte_bus_fslmc -ldl -lrte_pmd_avf
> > > > > -lrte_pmd_crypto_scheduler -lrte_pmd_netvsc -lrte_pmd_vhost
> > > > > -lrte_bus_dpaa -lrte_mempool_dpaa2 -lrte_common_octeontx
> > > > > -lrte_pmd_liquidio -lrte_pmd_ifc -Wl,-Bdynamic -lnuma
> > > > > -lrte_pmd_enic -lrte_common_cpt -pthread -lrte_pmd_octeontx_crypto
> > > > > -lrte_pmd_qat -lrte_bus_vmbus -lrte_pmd_null -lm -lrte_pmd_dpaa
> > > > > -lrte_bus_vdev -lrte_pmd_dpaa2 -lrte_pmd_skeleton_event
> > > > > -lrte_pmd_af_packet -lrte_pmd_octeontx -lrte_pmd_thunderx
> > > > > -lrte_pmd_ring -lrte_pmd_octeontx_event -lrte_pmd_sw_event
> > > > > -lrte_pmd_ark -lrte_mempool_octeontx -lrte_pmd_ixgbe -lrte_pmd_kni
> > > > > -lrte_mempool_ring -lrte_pmd_virtio_crypto -lrte_mempool_dpaa
> > > > > -lrte_pmd_dpaa2_cmdif -lrte_bus_pci -lrte_pmd_opdl_event
> > > > > -lrte_pmd_mlx5 -lrte_pmd_virtio -lrte_pmd_tap -lrte_pmd_caam_jr
> > > > > -lrte_pmd_dpaa2_sec -lrte_pmd_dpaa2_qdma -lrte_pmd_enetc
> > > > > -lrte_pmd_sfc -lrte_pmd_bnxt -lrte_pmd_dpaa2_event -lrte_pmd_cxgbe
> > > > > -Wl,--whole-archive -Wl,--no- as-needed -lrte_pmd_e1000
> > > > > -lrte_pmd_softnic -lrte_pmd_bond -lrte_pmd_fm10k -lrte_pmd_i40e
> > > > > -lrte_pmd_nfp -lrte_pmd_qede -Wl,--no- whole-archive
> > > > > -lrte_pmd_axgbe -lrte_pmd_ccp -lrte_pmd_ifpga_rawdev
> > > > > -lrte_pmd_bbdev_null -lrte_pmd_openssl -lrte_pmd_dsw_event
> > > > > -lrte_pmd_dpaa_event -lrte_mempool_stack -lrte_pmd_vdev_netvsc
> > > > > -lrte_pmd_dpaa_sec -lrte_pmd_skeleton_rawdev
> > > > > -lrte_pmd_octeontx_compress
> > > > >
> > > > > You'll notice there's no mlx5 or mnl in that list. I was using
> > > > > 18.11-
> > > > > rc2 since I cloned early yesterday. Perhaps meson determined not
> > > > > to put it in there for some reason?
> > > >
> > > > Were mlx5/mnl found at meson configure time?
> > > >
> > > > --
> > > > Kind regards,
> > > > Luca Boccassi
> > >
> > > Hi Luca, yes, it was:
> > >
> > > Library mnl found: YES
> > > Library mlx4 found: YES
> > > Library ibverbs found: YES
> > > Compiler for C supports argument -Wextra: YES Compiler for C supports
> > > argument -std=c11: YES Compiler for C supports argument
> > > -Wno-strict-prototypes: YES Compiler for C supports argument
> > > -D_BSD_SOURCE: YES Compiler for C supports argument -D_DEFAULT_SOURCE:
> > > YES Compiler for C supports argument -D_XOPEN_SOURCE=600: YES Checking
> > > whether type "struct mlx4_wqe_lso_seg" has member "mss_hdr_size": YES
> > > Configuring mlx4_autoconf.h using configuration Library mnl found: YES
> > > Library mlx5 found: YES Library ibverbs found: YES ...
> > > PKG_CONFIG_PATH=meson-private/ pkg-config --libs --static libdpdk
> > > -L/usr/local/lib/x86_64-linux-gnu -lrte_eventdev -lrte_power
> > > -lrte_ip_frag -lrte_hash -lrte_pdump -lrte_eal -lrte_pipeline
> > > -lrte_table -lrte_bbdev -lrte_bpf -lrte_vhost -lrte_metrics
> > > -lrte_jobstats -lrte_net -lrte_reorder -lrte_ring -lrte_mempool
> > > -lrte_security -lrte_compressdev -lrte_rawdev -lrte_mbuf -lrte_kvargs
> > > -lrte_port -lrte_pci -lrte_ethdev -lrte_gro -lrte_gso -lrte_cryptodev
> > > -lrte_sched -lrte_latencystats -lrte_efd -lrte_distributor -lrte_meter
> > > -lrte_acl -lrte_member -lrte_cmdline -lrte_lpm -lrte_kni -lrte_cfgfile
> > > -lrte_bitratestats -lrte_timer -lrte_flow_classify -lrte_pmd_ccp
> > > -lrte_mempool_bucket -lrte_pmd_failsafe -lrte_pmd_netvsc
> > > -lrte_pmd_null_crypto -lrte_bus_ifpga -lrte_pmd_atlantic
> > > -lrte_pmd_octeontx_event -lrte_pmd_avp -lrte_pmd_mlx4
> > > -lrte_common_dpaax -lrte_pmd_skeleton_rawdev -lrte_pmd_ena
> > > -lrte_pmd_opdl_event -lrte_bus_fslmc -lnuma -lrte_pmd_avf
> > > -lrte_pmd_crypto_scheduler -lrte_pmd_vhost -lrte_bus_dpaa
> > > -lrte_mempool_dpaa2 -lrte_common_octeontx -Wl,--no-as-needed -lcrypto
> > > -lrte_pmd_ifc -lrte_pmd_liquidio -lrte_pmd_enic -lrte_common_cpt
> > > -Wl,--no-whole-archive -lrte_bus_vmbus -lrte_pmd_octeontx_crypto
> > > -lrte_pmd_qat -lrte_pmd_ifpga_rawdev -lrte_pmd_dpaa -lrte_bus_vdev
> > > -lrte_pmd_bbdev_null -lrte_pmd_dpaa2 -lrte_pmd_skeleton_event
> > > -lrte_pmd_ring -lrte_pmd_af_packet -lrte_pmd_thunderx
> > > -lrte_pmd_dpaa_event -lrte_pmd_octeontx_compress -lrte_pmd_dpaa_sec
> > > -lrte_pmd_sw_event -Wl,--whole-archive -lrte_pmd_ark
> > > -lrte_mempool_octeontx -lrte_pmd_ixgbe -lrte_mempool_ring
> > > -lrte_pmd_kni -lrte_pmd_vmxnet3 -lrte_mempool_dpaa -lrte_bus_pci
> > > -lrte_pmd_dpaa2_cmdif -lrte_pmd_mlx5 -lrte_pmd_tap -lrte_pmd_caam_jr
> > > -lrte_pmd_dpaa2_sec -lm -lrte_pmd_dpaa2_qdma -lrte_pmd_enetc
> > > -lrte_pmd_virtio -lrte_pmd_bnxt -lrte_pmd_dpaa2_event -lrte_pmd_sfc
> > > -lrte_pmd_cxgbe -pthread -lrte_pmd_e1000 -lrte_pmd_softnic -ldl
> > > -lrte_pmd_null -lrte_pmd_bond -lrte_pmd_fm10k -lrte_pmd_i40e
> > > -lrte_pmd_nfp -lrte_pmd_qede -lrte_pmd_axgbe -Wl,-Bdynamic
> > > -lrte_pmd_openssl -lrte_pmd_octeontx -lrte_pmd_dsw_event
> > > -lrte_mempool_stack -lrte_pmd_virtio_crypto -lrte_pmd_vdev_netvsc
> >
> > Is this with latest DPDK from git? because I see the exact same as Luca:
> >
> > $ PKG_CONFIG_PATH=build/meson-private/ pkg-config --libs --static
> libdpdk | grep mlx
> > -L/usr/local/lib64 -lrte_telemetry -lrte_bpf -lrte_flow_classify -
> lrte_pipeline -lrte_table -lrte_port -lrte_vhost -lrte_security -
> lrte_sched -lrte_reorder -lrte_rawdev -lrte_pdump -lrte_power -lrte_meter
> -lrte_member -lrte_lpm -lrte_latencystats -lrte_kni -lrte_jobstats -
> lrte_ip_frag -lrte_gso -lrte_gro -lrte_eventdev -lrte_efd -
> lrte_distributor -lrte_cryptodev -lrte_compressdev -lrte_cfgfile -
> lrte_bitratestats -lrte_bbdev -lrte_acl -lrte_timer -lrte_hash -
> lrte_metrics -lrte_pci -lrte_ethdev -lrte_net -lrte_mbuf -lrte_mempool -
> lrte_ring -lrte_eal -lrte_kvargs -lrte_cmdline -L/usr/local/lib64 -
> lrte_kvargs -lrte_eal -lrte_ring -lrte_mempool -lrte_mbuf -lrte_pci -
> lrte_cryptodev -lrte_net -lrte_cmdline -lrte_ethdev -lrte_hash -lrte_timer
> -lrte_common_dpaax -lrte_eventdev -lrte_rawdev -lrte_bus_dpaa -
> lrte_bus_fslmc -lrte_bus_pci -lrte_common_octeontx -lrte_bus_vdev -
> lrte_meter -lrte_sched -lrte_ip_frag -lz -lrte_mempool_dpaa -
> lrte_mempool_dpaa2 -lrte_vhost -lrte_security -lrte_kni -lmnl -lmlx4 -
> libverbs -lmnl -lmlx5 -libverbs -lrte_bus_vmbus -lrte_mempool_octeontx -
> lpcap -lrte_port -lrte_lpm -lrte_acl -lrte_table -lrte_pipeline -lsze2 -
> lrte_gso -lIPSec_MB -lIPSec_MB -lrte_common_cpt -lrte_reorder -
> lrte_compressdev -lrte_pmd_dpaa -lrte_pmd_dpaa2 -lrte_pmd_dpaa2_sec -
> lrte_pmd_octeontx -lrte_bbdev -lrte_bus_ifpga -Wl,--whole-archive -
> lrte_mempool_bucket -lrte_mempool_ring -lrte_mempool_stack -
> lrte_pmd_af_packet -lrte_pmd_ark -lrte_pmd_atlantic -lrte_pmd_avf -
> lrte_pmd_avp -lrte_pmd_axgbe -lrte_pmd_bond -lrte_pmd_bnx2x -lrte_pmd_bnxt
> -lrte_pmd_cxgbe -lrte_pmd_e1000 -lrte_pmd_ena -lrte_pmd_enetc -
> lrte_pmd_enic -lrte_pmd_failsafe -lrte_pmd_fm10k -lrte_pmd_i40e -
> lrte_pmd_ifc -lrte_pmd_ixgbe -lrte_pmd_kmod -lrte_pmd_kni -
> lrte_pmd_liquidio -lrte_pmd_mlx4 -lrte_pmd_mlx5 -lrte_pmd_netvsc -
> lrte_pmd_nfp -lrte_pmd_null -lrte_pmd_pcap -lrte_pmd_qede -lrte_pmd_ring -
> lrte_pmd_sfc -lrte_pmd_softnic -lrte_pmd_szedata2 -lrte_pmd_tap -
> lrte_pmd_thunderx -lrte_pmd_vdev_netvsc -lrte_pmd_vhost -lrte_pmd_virtio -
> lrte_pmd_vmxnet3 -lrte_pmd_aesni_gcm -lrte_pmd_aesni_mb -lrte_pmd_caam_jr
> -lrte_pmd_ccp -lrte_pmd_dpaa_sec -lrte_pmd_null_crypto -
> lrte_pmd_octeontx_crypto -lrte_pmd_openssl -lrte_pmd_crypto_scheduler -
> lrte_pmd_virtio_crypto -lrte_pmd_octeontx_compress -lrte_pmd_qat -
> lrte_pmd_zlib -lrte_pmd_dpaa_event -lrte_pmd_dpaa2_event -
> lrte_pmd_octeontx_event -lrte_pmd_opdl_event -lrte_pmd_skeleton_event -
> lrte_pmd_sw_event -lrte_pmd_dsw_event -lrte_pmd_bbdev_null -
> lrte_pmd_skeleton_rawdev -lrte_pmd_dpaa2_cmdif -lrte_pmd_dpaa2_qdma -
> lrte_pmd_ifpga_rawdev -lrte_pmd_ioat_copy -Wl,--no-whole-archive -Wl,-
> Bdynamic -Wl,--no-as-needed -pthread -lm -ldl -lnuma -lbsd -lpcap -lcrypto
> -lcrypto -lz -lcrypto -ldl -pthread -lz
> 
> Hi Bruce, I tried with rc3 and a new clone from right now, and get the
> same results:
> 
> $ meson build
> The Meson build system
> Version: 0.45.1
> Source dir: /home/cburdick/dpdk
> Build dir: /home/cburdick/dpdk/build
> Build type: native build
> Project name: DPDK
> Native C compiler: cc (gcc 7.3.0 "cc (Ubuntu 7.3.0-27ubuntu1~18.04)
> 7.3.0")
> Build machine cpu family: x86_64
> Build machine cpu: x86_64
> Library numa found: YES
> Has header "numaif.h": YES
> Library bsd found: NO
> Checking for size of "void *": 8
> Compiler for C supports argument -Wsign-compare: YES
> Compiler for C supports argument -Wcast-qual: YES
> Compiler for C supports argument -Wno-address-of-packed-member: YES
> Fetching value of define "__SSE4_2__": 1
> Fetching value of define "__AES__": 1
> Fetching value of define "__PCLMUL__": 1
> Fetching value of define "__AVX__": 1
> Fetching value of define "__AVX2__": 1
> Fetching value of define "__AVX512F__":
> Compiler for C supports argument -Wno-format-truncation: YES
> Checking for size of "void *": 8
> Has header "linux/userfaultfd.h": YES
> Checking for size of "void *": 8
> Library elf found: NO
> Library jansson found: NO
> Program gen-pmdinfo-cfile.sh found: YES
> (/home/cburdick/dpdk/buildtools/gen-pmdinfo-cfile.sh)
> Compiler for C supports argument -Wno-format-truncation: YES
> Library libmusdk found: NO
> Compiler for C supports argument -Wno-cast-qual: YES
> Compiler for C supports argument -Wno-pointer-to-int-cast: YES
> Library z found: NO
> Compiler for C supports argument -Wno-uninitialized: YES
> Compiler for C supports argument -Wno-unused-parameter: YES
> Compiler for C supports argument -Wno-unused-variable: YES
> Compiler for C supports argument -Wno-misleading-indentation: YES
> Compiler for C supports argument -Wno-implicit-fallthrough: YES
> Checking for size of "void *": 8
> Compiler for C supports argument -Wno-unused-parameter: YES
> Compiler for C supports argument -Wno-unused-value: YES
> Compiler for C supports argument -Wno-strict-aliasing: YES
> Compiler for C supports argument -Wno-format-extra-args: YES
> Compiler for C supports argument -Wno-unused-variable: YES
> Compiler for C supports argument -Wno-missing-field-initializers: YES
> Compiler for C supports argument -Wno-sign-compare: YES
> Compiler for C supports argument -Wno-unused-value: YES
> Compiler for C supports argument -Wno-format: YES
> Compiler for C supports argument -Wno-error=format-security: YES
> Compiler for C supports argument -Wno-strict-aliasing: YES
> Compiler for C supports argument -Wno-unused-but-set-variable: YES
> Compiler for C supports argument -Wno-unused-value: YES
> Compiler for C supports argument -Wno-unused-but-set-variable: YES
> Library mnl found: YES
> Library mlx4 found: YES
> Library ibverbs found: YES
> Compiler for C supports argument -Wextra: YES
> Compiler for C supports argument -std=c11: YES
> Compiler for C supports argument -Wno-strict-prototypes: YES
> Compiler for C supports argument -D_BSD_SOURCE: YES
> Compiler for C supports argument -D_DEFAULT_SOURCE: YES
> Compiler for C supports argument -D_XOPEN_SOURCE=600: YES
> Checking whether type "struct mlx4_wqe_lso_seg" has member "mss_hdr_size":
> YES
> Configuring mlx4_autoconf.h using configuration
> Library mnl found: YES
> Library mlx5 found: YES
> Library ibverbs found: YES
> Compiler for C supports argument -Wextra: YES
> Compiler for C supports argument -std=c11: YES
> Compiler for C supports argument -Wno-strict-prototypes: YES
> Compiler for C supports argument -D_BSD_SOURCE: YES
> Compiler for C supports argument -D_DEFAULT_SOURCE: YES
> Compiler for C supports argument -D_XOPEN_SOURCE=600: YES
> Header <infiniband/mlx5dv.h> has symbol
> "MLX5DV_CQE_RES_FORMAT_CSUM_STRIDX": YES
> Header <infiniband/mlx5dv.h> has symbol
> "MLX5DV_CONTEXT_MASK_TUNNEL_OFFLOADS": YES
> Header <infiniband/mlx5dv.h> has symbol
> "MLX5DV_CONTEXT_FLAGS_MPW_ALLOWED": YES
> Header <infiniband/mlx5dv.h> has symbol
> "MLX5DV_CONTEXT_FLAGS_CQE_128B_COMP": YES
> Header <infiniband/mlx5dv.h> has symbol
> "MLX5DV_CQ_INIT_ATTR_FLAGS_CQE_PAD": YES
> Header <infiniband/mlx5dv.h> has symbol
> "mlx5dv_create_flow_action_packet_reformat": NO
> Header <infiniband/verbs.h> has symbol "IBV_FLOW_SPEC_MPLS": YES
> Header <infiniband/verbs.h> has symbol "IBV_WQ_FLAG_RX_END_PADDING": NO
> Header <linux/ethtool.h> has symbol "SUPPORTED_40000baseKR4_Full": YES
> Header <linux/ethtool.h> has symbol "SUPPORTED_40000baseCR4_Full": YES
> Header <linux/ethtool.h> has symbol "SUPPORTED_40000baseSR4_Full": YES
> Header <linux/ethtool.h> has symbol "SUPPORTED_40000baseLR4_Full": YES
> Header <linux/ethtool.h> has symbol "SUPPORTED_56000baseKR4_Full": YES
> Header <linux/ethtool.h> has symbol "SUPPORTED_56000baseCR4_Full": YES
> Header <linux/ethtool.h> has symbol "SUPPORTED_56000baseSR4_Full": YES
> Header <linux/ethtool.h> has symbol "SUPPORTED_56000baseLR4_Full": YES
> Header <linux/ethtool.h> has symbol
> "ETHTOOL_LINK_MODE_25000baseCR_Full_BIT": YES
> Header <linux/ethtool.h> has symbol
> "ETHTOOL_LINK_MODE_50000baseCR2_Full_BIT": YES
> Header <linux/ethtool.h> has symbol
> "ETHTOOL_LINK_MODE_100000baseKR4_Full_BIT": YES
> Header <linux/if_link.h> has symbol "IFLA_PHYS_SWITCH_ID": YES
> Header <linux/if_link.h> has symbol "IFLA_PHYS_PORT_NAME": YES
> Header <linux/if_link.h> has symbol "IFLA_VXLAN_COLLECT_METADATA": YES
> Header <linux/rtnetlink.h> has symbol "TCA_CHAIN": YES
> Header <linux/pkt_cls.h> has symbol "TCA_FLOWER_ACT": YES
> Header <linux/pkt_cls.h> has symbol "TCA_FLOWER_FLAGS": YES
> Header <linux/pkt_cls.h> has symbol "TCA_FLOWER_KEY_ETH_TYPE": YES
> Header <linux/pkt_cls.h> has symbol "TCA_FLOWER_KEY_ETH_DST": YES
> Header <linux/pkt_cls.h> has symbol "TCA_FLOWER_KEY_ETH_DST_MASK": YES
> Header <linux/pkt_cls.h> has symbol "TCA_FLOWER_KEY_ETH_SRC": YES
> Header <linux/pkt_cls.h> has symbol "TCA_FLOWER_KEY_ETH_SRC_MASK": YES
> Header <linux/pkt_cls.h> has symbol "TCA_FLOWER_KEY_IP_PROTO": YES
> Header <linux/pkt_cls.h> has symbol "TCA_FLOWER_KEY_IPV4_SRC": YES
> Header <linux/pkt_cls.h> has symbol "TCA_FLOWER_KEY_IPV4_SRC_MASK": YES
> Header <linux/pkt_cls.h> has symbol "TCA_FLOWER_KEY_IPV4_DST": YES
> Header <linux/pkt_cls.h> has symbol "TCA_FLOWER_KEY_IPV4_DST_MASK": YES
> Header <linux/pkt_cls.h> has symbol "TCA_FLOWER_KEY_IPV6_SRC": YES
> Header <linux/pkt_cls.h> has symbol "TCA_FLOWER_KEY_IPV6_SRC_MASK": YES
> Header <linux/pkt_cls.h> has symbol "TCA_FLOWER_KEY_IPV6_DST": YES
> Header <linux/pkt_cls.h> has symbol "TCA_FLOWER_KEY_IPV6_DST_MASK": YES
> Header <linux/pkt_cls.h> has symbol "TCA_FLOWER_KEY_TCP_SRC": YES
> Header <linux/pkt_cls.h> has symbol "TCA_FLOWER_KEY_TCP_SRC_MASK": YES
> Header <linux/pkt_cls.h> has symbol "TCA_FLOWER_KEY_TCP_DST": YES
> Header <linux/pkt_cls.h> has symbol "TCA_FLOWER_KEY_TCP_DST_MASK": YES
> Header <linux/pkt_cls.h> has symbol "TCA_FLOWER_KEY_UDP_SRC": YES
> Header <linux/pkt_cls.h> has symbol "TCA_FLOWER_KEY_UDP_SRC_MASK": YES
> Header <linux/pkt_cls.h> has symbol "TCA_FLOWER_KEY_UDP_DST": YES
> Header <linux/pkt_cls.h> has symbol "TCA_FLOWER_KEY_UDP_DST_MASK": YES
> Header <linux/pkt_cls.h> has symbol "TCA_FLOWER_KEY_VLAN_ID": YES
> Header <linux/pkt_cls.h> has symbol "TCA_FLOWER_KEY_VLAN_PRIO": YES
> Header <linux/pkt_cls.h> has symbol "TCA_FLOWER_KEY_VLAN_ETH_TYPE": YES
> Header <linux/pkt_cls.h> has symbol "TCA_FLOWER_KEY_TCP_FLAGS": YES
> Header <linux/pkt_cls.h> has symbol "TCA_FLOWER_KEY_TCP_FLAGS_MASK": YES
> Header <linux/pkt_cls.h> has symbol "TC_ACT_GOTO_CHAIN": YES
> Header <linux/tc_act/tc_vlan.h> has symbol "TCA_VLAN_PUSH_VLAN_PRIORITY":
> YES
> Header <linux/pkt_cls.h> has symbol "TCA_FLOWER_KEY_ENC_KEY_ID": YES
> Header <linux/pkt_cls.h> has symbol "TCA_FLOWER_KEY_ENC_IPV4_SRC": YES
> Header <linux/pkt_cls.h> has symbol "TCA_FLOWER_KEY_ENC_IPV4_SRC_MASK":
> YES
> Header <linux/pkt_cls.h> has symbol "TCA_FLOWER_KEY_ENC_IPV4_DST": YES
> Header <linux/pkt_cls.h> has symbol "TCA_FLOWER_KEY_ENC_IPV4_DST_MASK":
> YES
> Header <linux/pkt_cls.h> has symbol "TCA_FLOWER_KEY_ENC_IPV6_SRC": YES
> Header <linux/pkt_cls.h> has symbol "TCA_FLOWER_KEY_ENC_IPV6_SRC_MASK":
> YES
> Header <linux/pkt_cls.h> has symbol "TCA_FLOWER_KEY_ENC_IPV6_DST": YES
> Header <linux/pkt_cls.h> has symbol "TCA_FLOWER_KEY_ENC_IPV6_DST_MASK":
> YES
> Header <linux/pkt_cls.h> has symbol "TCA_FLOWER_KEY_ENC_UDP_SRC_PORT": YES
> Header <linux/pkt_cls.h> has symbol
> "TCA_FLOWER_KEY_ENC_UDP_SRC_PORT_MASK": YES
> Header <linux/pkt_cls.h> has symbol "TCA_FLOWER_KEY_ENC_UDP_DST_PORT": YES
> Header <linux/pkt_cls.h> has symbol
> "TCA_FLOWER_KEY_ENC_UDP_DST_PORT_MASK": YES
> Header <linux/tc_act/tc_tunnel_key.h> has symbol "TCA_ACT_TUNNEL_KEY": YES
> Header <linux/tc_act/tc_tunnel_key.h> has symbol
> "TCA_TUNNEL_KEY_ENC_DST_PORT": YES
> Header <linux/tc_act/tc_tunnel_key.h> has symbol "TCA_TUNNEL_KEY_NO_CSUM":
> YES
> Header <linux/tc_act/tc_pedit.h> has symbol
> "TCA_PEDIT_KEY_EX_HDR_TYPE_UDP": YES
> Header <rdma/rdma_netlink.h> has symbol "RDMA_NL_NLDEV": YES
> Header <rdma/rdma_netlink.h> has symbol "RDMA_NLDEV_CMD_GET": YES
> Header <rdma/rdma_netlink.h> has symbol "RDMA_NLDEV_CMD_PORT_GET": YES
> Header <rdma/rdma_netlink.h> has symbol "RDMA_NLDEV_ATTR_DEV_INDEX": YES
> Header <rdma/rdma_netlink.h> has symbol "RDMA_NLDEV_ATTR_DEV_NAME": YES
> Header <rdma/rdma_netlink.h> has symbol "RDMA_NLDEV_ATTR_PORT_INDEX": YES
> Header <rdma/rdma_netlink.h> has symbol "RDMA_NLDEV_ATTR_NDEV_INDEX": NO
> Checking whether type "struct mlx5dv_sw_parsing_caps" has member
> "sw_parsing_offloads": YES
> Checking whether type "struct ibv_counter_set_init_attr" has member
> "counter_set_id": YES
> Checking whether type "struct ibv_counters_init_attr" has member
> "comp_mask": NO
> Configuring mlx5_autoconf.h using configuration
> Library libmusdk found: NO
> Library libmusdk found: NO
> Library pcap found: NO
> Compiler for C supports argument -Wno-unused-parameter: YES
> Compiler for C supports argument -Wno-sign-compare: YES
> Compiler for C supports argument -Wno-missing-prototypes: YES
> Compiler for C supports argument -Wno-cast-qual: YES
> Compiler for C supports argument -Wno-unused-function: YES
> Compiler for C supports argument -Wno-unused-variable: YES
> Compiler for C supports argument -Wno-strict-aliasing: YES
> Compiler for C supports argument -Wno-missing-prototypes: YES
> Compiler for C supports argument -Wno-unused-value: YES
> Compiler for C supports argument -Wno-format-nonliteral: YES
> Compiler for C supports argument -Wno-shift-negative-value: YES
> Compiler for C supports argument -Wno-unused-but-set-variable: YES
> Compiler for C supports argument -Wno-missing-declarations: YES
> Compiler for C supports argument -Wno-maybe-uninitialized: YES
> Compiler for C supports argument -Wno-strict-prototypes: YES
> Compiler for C supports argument -Wno-shift-negative-value: YES
> Compiler for C supports argument -Wno-implicit-fallthrough: YES
> Compiler for C supports argument -Wno-format-extra-args: YES
> Compiler for C supports argument -Wno-visibility: YES
> Compiler for C supports argument -Wno-empty-body: YES
> Compiler for C supports argument -Wno-invalid-source-encoding: YES
> Compiler for C supports argument -Wno-sometimes-uninitialized: YES
> Compiler for C supports argument -Wno-pointer-bool-conversion: YES
> Checking for size of "void *": 8
> Compiler for C supports argument -Wno-strict-aliasing: YES
> Compiler for C supports argument -Wextra: YES
> Compiler for C supports argument -Wdisabled-optimization: YES
> Compiler for C supports argument -Waggregate-return: YES
> Compiler for C supports argument -Wnested-externs: YES
> Compiler for C supports argument -Wbad-function-cast: YES
> Compiler for C supports argument -Wno-sign-compare: YES
> Compiler for C supports argument -Wno-unused-parameter: YES
> Compiler for C supports argument -Wno-unused-variable: YES
> Compiler for C supports argument -Wno-empty-body: YES
> Compiler for C supports argument -Wno-unused-but-set-variable: YES
> Library sze2 found: NO
> Header <linux/pkt_cls.h> has symbol "TCA_FLOWER_UNSPEC": YES
> Header <linux/pkt_cls.h> has symbol "TCA_FLOWER_KEY_VLAN_PRIO": YES
> Header <linux/pkt_cls.h> has symbol "TCA_BPF_UNSPEC": YES
> Header <linux/pkt_cls.h> has symbol "TCA_BPF_FD": YES
> Header <linux/tc_act/tc_bpf.h> has symbol "TCA_ACT_BPF_UNSPEC": YES
> Header <linux/tc_act/tc_bpf.h> has symbol "TCA_ACT_BPF_FD": YES
> Configuring tap_autoconf.h using configuration
> Compiler for C supports argument -fno-prefetch-loop-arrays: YES
> Compiler for C supports argument -Wno-maybe-uninitialized: YES
> Compiler for C supports argument -Wall: YES
> Compiler for C supports argument -Wextra: YES
> Compiler for C supports argument -D_BSD_SOURCE: YES
> Compiler for C supports argument -D_DEFAULT_SOURCE: YES
> Compiler for C supports argument -D_XOPEN_SOURCE=600: YES
> Compiler for C supports argument -Wno-unused-parameter: YES
> Compiler for C supports argument -Wno-unused-value: YES
> Compiler for C supports argument -Wno-strict-aliasing: YES
> Compiler for C supports argument -Wno-format-extra-args: YES
> Library IPSec_MB found: NO
> Library IPSec_MB found: NO
> Found pkg-config: /usr/bin/pkg-config (0.29.1)
> Native dependency libcrypto found: YES 1.1.0g
> Library libsso_kasumi found: NO
> Library libmusdk found: NO
> Dependency libcrypto found: YES (cached)
> Dependency libcrypto found: YES (cached)
> Library libsso_zuc found: NO
> Dependency libisal found: NO
> Dependency zlib found: NO
> Compiler for C supports argument -Wno-sign-compare: YES
> Compiler for C supports argument -Wno-unused-value: YES
> Compiler for C supports argument -Wno-format: YES
> Compiler for C supports argument -Wno-error=format-security: YES
> Compiler for C supports argument -Wno-strict-aliasing: YES
> Compiler for C supports argument -Wno-unused-but-set-variable: YES
> Library execinfo found: NO
> Compiler for C supports argument -Wno-format-truncation: YES
> Dependency zlib found: NO
> Library execinfo found: NO
> Program doxygen found: NO
> Program sphinx-build found: NO
> kernel/linux/kni/meson.build:16: WARNING: Passed invalid keyword argument
> "console".
> WARNING: This will become a hard error in the future.
> WARNING: Unknown keyword arguments in target rte_kni: console
> Configuring rte_build_config.h using configuration
> Program buildtools/symlink-drivers-solibs.sh found: YES (/bin/sh
> /home/cburdick/dpdk/buildtools/symlink-drivers-solibs.sh)
> Message:
> =================
> Libraries Enabled
> =================
> 
> libs:
> \tcompat, cmdline, kvargs, eal, ring, mempool, mbuf, net,
> \tethdev, pci, metrics, hash, timer, acl, bbdev, bitratestats,
> \tcfgfile, compressdev, cryptodev, distributor, efd, eventdev, gro, gso,
> \tip_frag, jobstats, kni, latencystats, lpm, member, meter, power,
> \tpdump, rawdev, reorder, sched, security, vhost, port, table,
> \tpipeline, flow_classify, bpf,
> 
> Build targets in project: 411
> Found ninja-1.8.2 at /usr/bin/ninja
> [cburdick@dev01 ~/dpdk] (master)
> $ cd build
> [cburdick@dev01 ~/dpdk/build] (master)
> $ ninja
> [1428/1431] Generating igb_uio with a custom command.
> make: Entering directory '/usr/src/linux-headers-4.15.0-20-generic'
> Makefile:976: "Cannot use CONFIG_STACK_VALIDATION=y, please install
> libelf-dev, libelf-devel or elfutils-libelf-devel"
>   CC [M]  /home/cburdick/dpdk/build/kernel/linux/igb_uio/igb_uio.o
>   Building modules, stage 2.
>   MODPOST 1 modules
>   CC      /home/cburdick/dpdk/build/kernel/linux/igb_uio/igb_uio.mod.o
>   LD [M]  /home/cburdick/dpdk/build/kernel/linux/igb_uio/igb_uio.ko
> make: Leaving directory '/usr/src/linux-headers-4.15.0-20-generic'
> [1431/1431] Generating rte_kni with a custom command.
> make: Entering directory '/usr/src/linux-headers-4.15.0-20-generic'
> Makefile:976: "Cannot use CONFIG_STACK_VALIDATION=y, please install
> libelf-dev, libelf-devel or elfutils-libelf-devel"
>   CC [M]  /home/cburdick/dpdk/build/kernel/linux/kni/kni_net.o
>   CC [M]  /home/cburdick/dpdk/build/kernel/linux/kni/kni_misc.o
>   CC [M]  /home/cburdick/dpdk/build/kernel/linux/kni/kni_ethtool.o
>   CC [M]
> /home/cburdick/dpdk/build/kernel/linux/kni/ethtool/ixgbe/ixgbe_ethtool.o
>   CC [M]
> /home/cburdick/dpdk/build/kernel/linux/kni/ethtool/ixgbe/ixgbe_82599.o
>   CC [M]
> /home/cburdick/dpdk/build/kernel/linux/kni/ethtool/ixgbe/ixgbe_api.o
>   CC [M]
> /home/cburdick/dpdk/build/kernel/linux/kni/ethtool/ixgbe/ixgbe_x540.o
>   CC [M]
> /home/cburdick/dpdk/build/kernel/linux/kni/ethtool/ixgbe/ixgbe_common.o
>   CC [M]
> /home/cburdick/dpdk/build/kernel/linux/kni/ethtool/ixgbe/ixgbe_phy.o
>   CC [M]
> /home/cburdick/dpdk/build/kernel/linux/kni/ethtool/ixgbe/ixgbe_82598.o
>   CC [M]
> /home/cburdick/dpdk/build/kernel/linux/kni/ethtool/ixgbe/ixgbe_main.o
>   CC [M]
> /home/cburdick/dpdk/build/kernel/linux/kni/ethtool/ixgbe/kcompat.o
>   CC [M]
> /home/cburdick/dpdk/build/kernel/linux/kni/ethtool/igb/e1000_82575.o
>   CC [M]
> /home/cburdick/dpdk/build/kernel/linux/kni/ethtool/igb/e1000_i210.o
>   CC [M]
> /home/cburdick/dpdk/build/kernel/linux/kni/ethtool/igb/e1000_mbx.o
>   CC [M]
> /home/cburdick/dpdk/build/kernel/linux/kni/ethtool/igb/e1000_api.o
>   CC [M]
> /home/cburdick/dpdk/build/kernel/linux/kni/ethtool/igb/igb_main.o
>   CC [M]
> /home/cburdick/dpdk/build/kernel/linux/kni/ethtool/igb/igb_vmdq.o
>   CC [M]
> /home/cburdick/dpdk/build/kernel/linux/kni/ethtool/igb/e1000_manage.o
>   CC [M]
> /home/cburdick/dpdk/build/kernel/linux/kni/ethtool/igb/igb_ethtool.o
>   CC [M]
> /home/cburdick/dpdk/build/kernel/linux/kni/ethtool/igb/igb_param.o
>   CC [M]
> /home/cburdick/dpdk/build/kernel/linux/kni/ethtool/igb/e1000_mac.o
>   CC [M]
> /home/cburdick/dpdk/build/kernel/linux/kni/ethtool/igb/e1000_phy.o
>   CC [M]
> /home/cburdick/dpdk/build/kernel/linux/kni/ethtool/igb/e1000_nvm.o
>   LD [M]  /home/cburdick/dpdk/build/kernel/linux/kni/rte_kni.o
>   Building modules, stage 2.
>   MODPOST 1 modules
>   CC      /home/cburdick/dpdk/build/kernel/linux/kni/rte_kni.mod.o
>   LD [M]  /home/cburdick/dpdk/build/kernel/linux/kni/rte_kni.ko
> make: Leaving directory '/usr/src/linux-headers-4.15.0-20-generic'
> [cburdick@dev01 ~/dpdk/build] (master)
> $ PKG_CONFIG_PATH=meson-private/ pkg-config --libs --static libdpdk|grep
> mlx
> -L/usr/local/lib/x86_64-linux-gnu -lrte_flow_classify -lrte_eventdev -
> lrte_ip_frag -lrte_power -lrte_hash -lrte_pdump -lrte_pipeline -lrte_table
> -lrte_mbuf -lrte_bbdev -lrte_bpf -lrte_vhost -lrte_metrics -lrte_mempool -
> lrte_jobstats -lrte_reorder -lrte_net -lrte_security -lrte_eal -lrte_ring
> -lrte_ethdev -lrte_compressdev -lrte_rawdev -lrte_kvargs -lrte_pci -
> lrte_cfgfile -lrte_gro -lrte_gso -lrte_cryptodev -lrte_latencystats -
> lrte_sched -lrte_efd -lrte_distributor -lrte_acl -lrte_member -
> lrte_cmdline -lrte_lpm -lrte_meter -lrte_kni -lrte_bitratestats -
> lrte_timer -lrte_port -lrte_mempool_bucket -lrte_pmd_vdev_netvsc -
> lrte_pmd_ark -lrte_pmd_failsafe -lrte_pmd_netvsc -lrte_pmd_null_crypto -
> lrte_bus_ifpga -lrte_common_dpaax -lrte_pmd_ixgbe -lrte_mempool_ring -
> lrte_pmd_kni -lrte_pmd_vmxnet3 -lrte_pmd_mlx4 -lrte_pmd_virtio -Wl,--no-
> as-needed -lrte_mempool_dpaa -lrte_pmd_ena -lrte_bus_fslmc -lrte_pmd_avf -
> lrte_pmd_dpaa2_sec -lrte_common_octeontx -lrte_pmd_skeleton_rawdev -
> lrte_pmd_crypto_scheduler -lrte_pmd_dpaa2_qdma -lrte_pmd_vhost -ldl -
> lrte_bus_dpaa -lrte_pmd_fm10k -lrte_pmd_bnxt -lrte_pmd_qat -lrte_pmd_bond
> -lrte_pmd_axgbe -lrte_pmd_dpaa2 -lrte_pmd_skeleton_event -
> lrte_pmd_dpaa_event -lrte_mempool_stack -pthread -lrte_pmd_ccp -
> lrte_pmd_octeontx_compress -lrte_pmd_sw_event -lrte_mempool_octeontx -Wl,-
> Bdynamic -lrte_pmd_dpaa_sec -lrte_pmd_atlantic -lrte_pmd_octeontx_event -
> lrte_pmd_avp -lrte_bus_pci -lrte_pmd_dpaa2_cmdif -lrte_pmd_mlx5 -
> lrte_pmd_opdl_event -lrte_pmd_tap -lrte_pmd_caam_jr -lrte_pmd_sfc -lcrypto
> -lrte_pmd_enetc -lrte_mempool_dpaa2 -lrte_pmd_dpaa2_event -lrte_pmd_ifc -
> lrte_pmd_liquidio -lrte_pmd_cxgbe -lm -lrte_pmd_enic -lrte_bus_vdev -
> lrte_pmd_e1000 -lrte_pmd_softnic -lrte_pmd_ifpga_rawdev -lrte_bus_vmbus -
> lrte_pmd_octeontx_crypto -lrte_pmd_null -lnuma -lrte_common_cpt -
> lrte_pmd_nfp -lrte_pmd_qede -lrte_pmd_i40e -lrte_pmd_dpaa -Wl,--whole-
> archive -lrte_pmd_bbdev_null -lrte_pmd_af_packet -lrte_pmd_thunderx -
> lrte_pmd_openssl -lrte_pmd_octeontx -lrte_pmd_dsw_event -Wl,--no-whole-
> archive -lrte_pmd_ring -lrte_pmd_virtio_crypto

That is strange. Can you try one last thing - can you update meson with "pip3 install --upgrade meson" and see if that makes any difference? [If you are using your distro's meson from /usr/bin right now, you'll probably also need to run "hash meson" afterwards too].
Perhaps we have a hidden dependency on later meson versions or something like that.

/Bruce

Re: [dpdk-dev] [PATCH 1/1] eal: Don't fail secondary if primary is missing tailqs

[Luca Boccassi]

On Thu, 2018-11-15 at 17:01 +0000, Richardson, Bruce wrote:
> > -----Original Message-----
> > From: Burdick, Cliff [mailto:Cliff.Burdick@viasat.com]
> > Sent: Thursday, November 15, 2018 4:55 PM
> > To: Richardson, Bruce <bruce.richardson@intel.com>
> > Cc: Luca Boccassi <bluca@debian.org>; Thomas Monjalon
> > <thomas@monjalon.net>; Burakov, Anatoly <anatoly.burakov@intel.com>
> > ;
> > dev@dpdk.org
> > Subject: RE: [dpdk-dev] [PATCH 1/1] eal: Don't fail secondary if
> > primary
> > is missing tailqs
> > 
> > 
> > 
> > -----Original Message-----
> > From: Bruce Richardson [mailto:bruce.richardson@intel.com]
> > Sent: Thursday, November 15, 2018 8:41 AM
> > To: Burdick, Cliff
> > Cc: Luca Boccassi; Thomas Monjalon; Burakov, Anatoly; dev@dpdk.org
> > Subject: Re: [dpdk-dev] [PATCH 1/1] eal: Don't fail secondary if
> > primary
> > is missing tailqs
> > 
> > > On Thu, Nov 15, 2018 at 04:15:36PM +0000, Burdick, Cliff wrote:
> > > > 
> > > > 
> > > > -----Original Message-----
> > > > From: Luca Boccassi [mailto:bluca@debian.org]
> > > > Sent: Thursday, November 15, 2018 1:33 AM
> > > > To: Burdick, Cliff; Bruce Richardson
> > > > Cc: Thomas Monjalon; Burakov, Anatoly; dev@dpdk.org
> > > > Subject: Re: [dpdk-dev] [PATCH 1/1] eal: Don't fail secondary
> > > > if
> > > > primary is missing tailqs
> > > > 
> > > > > On Wed, 2018-11-14 at 18:24 +0000, Burdick, Cliff wrote:
> > > > > > 
> > > > > > -----Original Message-----
> > > > > > From: Luca Boccassi [mailto:bluca@debian.org]
> > > > > > Sent: Wednesday, November 14, 2018 10:15 AM
> > > > > > To: Burdick, Cliff; Bruce Richardson
> > > > > > Cc: Thomas Monjalon; Burakov, Anatoly; dev@dpdk.org
> > > > > > Subject: Re: [dpdk-dev] [PATCH 1/1] eal: Don't fail
> > > > > > secondary if
> > > > > > primary is missing tailqs
> > > > > > 
> > > > > > > On Wed, 2018-11-14 at 17:40 +0000, Burdick, Cliff wrote:
> > > > > > > > 
> > > > > > > > -----Original Message-----
> > > > > > > > From: Bruce Richardson [mailto:bruce.richardson@intel.c
> > > > > > > > om]
> > > > > > > > Sent: Wednesday, November 14, 2018 3:48 AM
> > > > > > > > To: Burdick, Cliff
> > > > > > > > Cc: Thomas Monjalon; Burakov, Anatoly; dev@dpdk.org
> > > > > > > > Subject: Re: [dpdk-dev] [PATCH 1/1] eal: Don't fail
> > > > > > > > secondary
> > > > > > > > if primary is missing tailqs
> > > > > > > > 
> > > > > > > > On Tue, Nov 13, 2018 at 11:42:51PM +0000, Burdick,
> > > > > > > > Cliff
> > 
> > wrote:
> > > > > > > > > > 
> > > > > > > > > > ________________________________________
> > > > > > > > > > From: Thomas Monjalon [thomas@monjalon.net]
> > > > > > > > > > Sent: Tuesday, November 13, 2018 2:18 PM
> > > > > > > > > > To: Burdick, Cliff
> > > > > > > > > > Cc: Burakov, Anatoly; dev@dpdk.org;
> > > > > > > > > > bruce.richardson@intel.co m
> > > > > > > > > > Subject: Re: [dpdk-dev] [PATCH 1/1] eal: Don't fail
> > > > > > > > > > secondary if primary is missing tailqs
> > > > > > > > > > 
> > > > > > > > > > 13/11/2018 23:08, Burdick, Cliff:
> > > > > > > > > > > From: Thomas Monjalon [mailto:thomas@monjalon.net
> > > > > > > > > > > ]
> > > > > > > > > > > > 13/11/2018 17:38, Burdick, Cliff:
> > > > > > > > > > > > > From: Thomas Monjalon [mailto:thomas@monjalon
> > > > > > > > > > > > > .net]
> > > > > > > > > > > > > 13/11/2018 16:45, Burdick, Cliff:
> > > > > > > > > > > > > > From: Burakov, Anatoly
> > 
> > [mailto:anatoly.burakov@intel.
> > > > > > > > > > > > > > com]
> > > > > > > > > > > > > > > On 13-Nov-18 9:21 AM, Thomas Monjalon
> > > > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > > > 13/11/2018 00:33, Burdick, Cliff:
> > > > > > > > > > > > > > > > > This patch was submitted by Jean
> > > > > > > > > > > > > > > > > Tourrilhes
> > > > > > > > > > > > > > > > > over two years ago, but didn't
> > > > > > > > > > > > > > > > > receive any
> > 
> > responses.
> > > > > > > > > > > > > > > > > I hit the same issue recently when
> > > > > > > > > > > > > > > > > trying to
> > > > > > > > > > > > > > > > > use cgo
> > > > > > > > > > > > > > > > > (Golang) as a primary process linked
> > > > > > > > > > > > > > > > > to
> > > > > > > > > > > > > > > > > libdpdk.a against a C++ application
> > > > > > > > > > > > > > > > > linked
> > > > > > > > > > > > > > > > > against the same library.> > >
> > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > The question is to know why you don't
> > > > > > > > > > > > > > > > have the
> > > > > > > > > > > > > > > > same constructors in primary and
> > > > > > > > > > > > > > > > seconday?
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > I've hit similar things in the past. I
> > > > > > > > > > > > > > > believe
> > > > > > > > > > > > > > > it was caused by our build system
> > > > > > > > > > > > > > > stripping out
> > > > > > > > > > > > > > > unused libraries (such as
> > > > > > > > > > > > > > > rte_hash) from the binary and thus not
> > > > > > > > > > > > > > > calling
> > > > > > > > > > > > > > > the constructor in the primary, but doing
> > > > > > > > > > > > > > > so in
> > > > > > > > > > > > > > > the secondary (or something to that
> > > > > > > > > > > > > > > effect). In
> > > > > > > > > > > > > > > any case, this is caused by linking
> > > > > > > > > > > > > > > different
> > > > > > > > > > > > > > > number of libraries to primary and
> > > > > > > > > > > > > > > secondary,
> > > > > > > > > > > > > > > and should probably be fixed in the build
> > > > > > > > > > > > > > > system, not in the tailqs code (unless we
> > > > > > > > > > > > > > > specifically support having different
> > > > > > > > > > > > > > > linked
> > > > > > > > > > > > > > > libraries to primary and secondary?).> >
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > Right, I think the original author of the
> > > > > > > > > > > > > > patch
> > > > > > > > > > > > > > stated the reasons in the link I provided.
> > > > > > > > > > > > > > The
> > > > > > > > > > > > > > build system seems like the most
> > > > > > > > > > > > > > appropriate place
> > > > > > > > > > > > > > to fix it, but the patch got me going
> > > > > > > > > > > > > > quickly. I
> > > > > > > > > > > > > > think the question is whether you want DPDK
> > > > > > > > > > > > > > to
> > > > > > > > > > > > > > support these other ways of linking.
> > > > > > > > > > > > > > I'm
> > > > > > > > > > > > > > certainly not the first to use cgo, since
> > > > > > > > > > > > > > there's
> > > > > > > > > > > > > > a virtual switch project doing the same:
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > https://urldefense.proofpoint.com/v2/url?u=
> > > > > > > > > > > > > > https-3
> > > > > > > > > > > > > > A__
> > > > > > > > > > > > > > gith
> > > > > > > > > > > > > > ub.co
> > > > > > > > > > > > > > m_lago
> > > > > > > > > > > > > > pu
> > > > > > > > > > > > > > s_vsw&d=DwICAg&c=jcv3orpCsv7C4ly8-
> > > > > > > > > > > > > > ubDoUfrxF5xIGWmptxGWP5vi5w&r =m1RLQ OG
> > > > > > > > > > > > > > Okz9MauvVLZmiGtyWc5mA7DejbPFNE1IDj-
> > > > > > > > > > > > > > 4&m=hQqVCNwW7eoEzB_hLFK97i8 idS8FI qX
> > > > > > > > > > > > > > oPeclwsIZq7Y&s=BMoBlwkqljwWIBY3SE3pPMCfVnOU
> > > > > > > > > > > > > > lDuZLrn
> > > > > > > > > > > > > > o4-
> > > > > > > > > > > > > > SojKM&e=
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > They don't use primary/secondary processes,
> > > > > > > > > > > > > > though, so the issue is  never hit. I'm in
> > > > > > > > > > > > > > a
> > > > > > > > > > > > > > situation where using cgo seemed like the
> > > > > > > > > > > > > > easiest
> > > > > > > > > > > > > > path to accomplish what I'm doing since I
> > > > > > > > > > > > > > needed
> > > > > > > > > > > > > > specialized  libraries for it that were not
> > > > > > > > > > > > > > available in C/C++. At some point I  bet
> > > > > > > > > > > > > > someone
> > > > > > > > > > > > > > would use Cython to start linking against
> > > > > > > > > > > > > > DPDK as
> > > > > > > > > > > > > > well,  and we'd likely run into the same
> > > > > > > > > > > > > > issue.> >
> > > > > > > > > > > > > > > > For sure, we want to support using DPDK
> > > > > > > > > > > > > > > > with
> > 
> > cgo or cython.
> > > > > > > > > > > > > > But it is not clear what is the relation
> > > > > > > > > > > > > > with not
> > > > > > > > > > > > > > having the same compilation for primary and
> > 
> > secondary.
> > > > > > > > > > > > > > Please
> > > > > > > > > > > > > > could you elaborate?> > >
> > > > > > > > > > > > > 
> > > > > > > > > > > > > Hi Thomas, I think Jean explained it well
> > > > > > > > > > > > > here:
> > > > > > > > > > > > > https://urldefense.proofpoint.com/v2/url?u=ht
> > > > > > > > > > > > > tps-3A_
> > > > > > > > > > > > > _de
> > > > > > > > > > > > > v.dp
> > > > > > > > > > > > > dk.narkive.
> > > > > > > > > > > > > com_ZM3a7QD1_dpdk-2Ddev-2Dbug-2Dstatic-
> > > > > > > > > > > > > 2Dconstructor
> > > > > > > > > > > > > s-
> > > > > > > > > > > > > 2Dconsider
> > > > > > > > > > > > > ed-2De
> > > > > > > > > > > > > vil&d=DwICAg&c=jcv3orpCsv7C4ly8-
> > > > > > > > > > > > > ubDoUfrxF5xIGWmptxGWP5vi5w&r=m1R LQOGOk
> > > > > > > > > > > > > z9MauvVLZmiGtyWc5mA7DejbPFNE1IDj-
> > > > > > > > > > > > > 4&m=C69wDgrjDX8_oXp1M_3bnmWOOZd GqwBBG
> > > > > > > > > > > > > 9vzkyGDWGQ&s=YYn2N7WrzJpH1ptNrLZad0nPAQdrUyqB
> > > > > > > > > > > > > ckk2uFu
> > > > > > > > > > > > > WYP
> > > > > > > > > > > > > Q&e=
> > > > > > > > > > > > > 
> > > > > > > > > > > > > "The build system of the application does not
> > > > > > > > > > > > > have
> > > > > > > > > > > > > all the subtelties of the DPDK build system,
> > > > > > > > > > > > > and
> > > > > > > > > > > > > ends up including
> > > > > > > > > > > > > *all*
> > > > > > > > > > > > > the constructors, wether they are used or not
> > > > > > > > > > > > > in the
> > > > > > > > > > > > > code.
> > > > > > > > > > > > > Moreover, they are included in a different
> > > > > > > > > > > > > order.
> > > > > > > > > > > > > Actually,
> > > > > > > > > > > > > by default the builds include no constructors
> > > > > > > > > > > > > at all
> > > > > > > > > > > > > (which is a big fail), so the library needs
> > > > > > > > > > > > > to be
> > > > > > > > > > > > > included with --whole-archive (see Snort DPDK
> > > > > > > > > > > > > instructions)."
> > > > > > > > > > > > > 
> > > > > > > > > > > > > I will get to the bottom of my exact case to
> > > > > > > > > > > > > understand what's happening, but my primary
> > > > > > > > > > > > > application is a cgo application that I'm
> > > > > > > > > > > > > linking to
> > > > > > > > > > > > > by using almost exactly the same flags that
> > > > > > > > > > > > > are used
> > > > > > > > > > > > > in the DPDK build system to build examples.
> > > > > > > > > > > > > The DPDK
> > > > > > > > > > > > > libraries I'm linking against is a single
> > > > > > > > > > > > > location
> > > > > > > > > > > > > for both primary and secondary; in other
> > > > > > > > > > > > > words, I
> > 
> > don't build DPDK twice.
> > > > > > > > > > > > > 
> > > > > > > > > > > > > OK I understand, thanks.
> > > > > > > > > > > > > 
> > > > > > > > > > > > > You had alluded to a pkg-config for DPDK in
> > > > > > > > > > > > > the 2015
> > > > > > > > > > > > > thread, which cgo can use, but I don't know
> > > > > > > > > > > > > if that
> > > > > > > > > > > > > ever was implemented. Cgo can use pkg-config
> > > > > > > > > > > > > if it's
> > > > > > > > > > > > > available, otherwise the only tools are
> > > > > > > > > > > > > specifying
> > > > > > > > > > > > > LDFLAGS and CFLAGS into their build system.
> > > > > > > > > > > > 
> > > > > > > > > > > > Yes, the right answer is still pkg-config :)
> > > > > > > > > > > > The good
> > > > > > > > > > > > news is that it is now implemented thanks to
> > > > > > > > > > > > the meson
> > > > > > > > > > > > build
> > > > > > > > > > > > system:
> > > > > > > > > > > > 
> > > > > > > > > > > > https://urldefense.proofpoint.com/v2/url?u=http
> > > > > > > > > > > > -3A__gi
> > > > > > > > > > > > t.d
> > > > > > > > > > > > pdk.
> > > > > > > > > > > > org_dp
> > > > > > > > > > > > dk_tree_doc_build-2Dsdk-2Dmeson.txt-
> > > > > > > > > > > > 23n182&d=DwICAg&c=jcv3orpCsv7C4
> > > > > > > > > > > > ly8-
> > > > > > > > > > > > ubDoUfrxF5xIGWmptxGWP5vi5w&r=m1RLQOGOkz9MauvVLZ
> > > > > > > > > > > > miGtyWc
> > > > > > > > > > > > 5mA
> > > > > > > > > > > > 7Dej
> > > > > > > > > > > > bP
> > > > > > > > > > > > FNE1IDj-
> > > > > > > > > > > > > 4&m=C69wDgrjDX8_oXp1M_3bnmWOOZdGqwBBG9vzkyGDW
> > > > > > > > > > > > > GQ&s=oC
> > > > > > > > > > > > > 86K
> > > > > > > > > > > > > D_R
> > > > > > > > > > > > 
> > > > > > > > > > > > J1T6rfzi3x5zFT1Ri13ELpKmsyFqpgDbgFg&e=
> > > > > > > > > > > 
> > > > > > > > > > > Hi Thomas, are there instructions on how to use
> > > > > > > > > > > pkg-config to build the mlx4/5 PMD? I noticed a
> > > > > > > > > > > patch
> > > > > > > > > > > was submitted in September to add support for it,
> > > > > > > > > > > but
> > > > > > > > > > > that link you provided on using meson doesn't say
> > > > > > > > > > > how to
> > > > > > > > > > > build specific drivers. It appears to be disabled
> > > > > > > > > > > by
> > 
> > default.
> > > > > > > > > > > If the dependency is found, meson will enable the
> > > > > > > > > > > PMD
> > > > > > > > > > > when building DPDK.
> > > > > > > > > > 
> > > > > > > > > > Do you know where exactly that is? I've been using
> > > > > > > > > > mlx5
> > > > > > > > > > for a while on this system, and I can see that
> > > > > > > > > > 18.11-rc2
> > > > > > > > > > meson
> > > > > > > > > > build+ninja built the pmd, but it's not on the --
> > > > > > > > > > libs
> > > > > > > > > > build+listing
> > > > > > > > > > for
> > > > > > > > > > pkg-config. Does it tell me what I was missing?
> > > > > > > > > > 
> > > > > > > > > 
> > > > > > > > > For dynamic linking of applications, the drivers are
> > > > > > > > > not
> > > > > > > > > normally linked in. Instead, they should be loaded
> > > > > > > > > from the
> > > > > > > > > drivers directory as .so files
> > > > > > > > > - normally by default in EAL as the driver .so's
> > > > > > > > > should be
> > > > > > > > > copied to the EAL_PMD_PATH where EAL finds them
> > 
> > automatically.
> > > > > > > > > [This applies to both meson and make builds, though
> > > > > > > > > only
> > > > > > > > > meson generates the .pc file for pkg-config]
> > > > > > > > > 
> > > > > > > > > If you are doing a static build, then you need to
> > > > > > > > > explicitly
> > > > > > > > > link in the drivers. You can get a list from pkg-
> > > > > > > > > config
> > > > > > > > > using the "
> > > > > > > > > --static" flag in this case. A good example of how to
> > > > > > > > > use
> > > > > > > > > pkg- config in this way can be found in the Makefiles
> > > > > > > > > for
> > > > > > > > > most examples, e.g. examples/helloworld/Makefile,
> > > > > > > > > reproduced
> > 
> > below.
> > > > > > > > > 
> > > > > > > > > Regards,
> > > > > > > > > /Bruce
> > > > > > > > > 
> > > > > > > > > all: shared
> > > > > > > > > .PHONY: shared static
> > > > > > > > > shared: build/$(APP)-shared
> > > > > > > > >         ln -sf $(APP)-shared build/$(APP)
> > > > > > > > > static: build/$(APP)-static
> > > > > > > > >         ln -sf $(APP)-static build/$(APP)
> > > > > > > > > 
> > > > > > > > > PC_FILE := $(shell pkg-config --path libdpdk) CFLAGS
> > > > > > > > > += -O3
> > > > > > > > > $(shell pkg-config --cflags libdpdk) LDFLAGS_SHARED =
> > > > > > > > > $(shell
> > > > > > > > > pkg- config -- libs libdpdk) LDFLAGS_STATIC = -Wl,-
> > > > > > > > > Bstatic
> > > > > > > > > $(shell pkg-config
> > > > > > > > > --
> > > > > > > > > static --libs libdpdk)
> > > > > > > > > 
> > > > > > > > > build/$(APP)-shared: $(SRCS-y) Makefile $(PC_FILE) |
> > > > > > > > > build
> > > > > > > > >         $(CC) $(CFLAGS) $(SRCS-y) -o $@ $(LDFLAGS)
> > > > > > > > > $(LDFLAGS_SHARED)
> > > > > > > > > 
> > > > > > > > > build/$(APP)-static: $(SRCS-y) Makefile $(PC_FILE) |
> > > > > > > > > build
> > > > > > > > >         $(CC) $(CFLAGS) $(SRCS-y) -o $@ $(LDFLAGS)
> > > > > > > > > $(LDFLAGS_STATIC)
> > > > > > > > > 
> > > > > > > > > build:
> > > > > > > > >         @mkdir -p $@
> > > > > > > > 
> > > > > > > > Thanks Bruce. I tried getting this to compile using
> > > > > > > > cgo, and
> > > > > > > > it's causing more pain than it's worth. I used the --
> > > > > > > > static
> > > > > > > > --libs options, and there were still numerous linker
> > > > > > > > errors,
> > > > > > > > some specific to mlx, and some not. Specifically
> > > > > > > > libmlx5 and
> > > > > > > > libmnl are both needed, but they're not part of the
> > > > > > > > linker
> > > > > > > > line from pkg-config. At this point I'll just break the
> > > > > > > > Go
> > > > > > > > application up into a separate C application that
> > > > > > > > handles all
> > > > > > > > the DPDK parts, and send messages between them.
> > > > > > > 
> > > > > > > Hi,
> > > > > > > 
> > > > > > > As far as I can see, both mnl and mlx5 (and all the other
> > > > > > > reverse
> > > > > > > dependencies) are listed correctly in the libdpdk.pc
> > > > > > > Libs.private entry, and pkg-config --libs --static
> > > > > > > libdpdk.pc
> > > > > > > does print them as intended. This is with 18.11-rc3.
> > > > > > > Are you sure everything is correct (pkg-config path is
> > > > > > > right, --
> > > > > > > static is used, etc)?
> > > > > > > 
> > > > > > > --
> > > > > > > Kind regards,
> > > > > > > Luca Boccassi
> > > > > > 
> > > > > > Hi Luca, here is what pkg-config gives:
> > > > > > 
> > > > > > PKG_CONFIG_PATH=meson-private/ pkg-config --libs --static
> > > > > > libdpdk
> > > > > > -L/usr/local/lib/x86_64-linux-gnu -lrte_eventdev
> > > > > > -lrte_power
> > > > > > -lrte_ip_frag -lrte_hash -lrte_pdump -lrte_eal
> > > > > > -lrte_pipeline
> > > > > > -lrte_table -lrte_bbdev -lrte_bpf -lrte_vhost -lrte_metrics
> > > > > > -lrte_jobstats -lrte_net -lrte_reorder -lrte_ring
> > > > > > -lrte_mempool
> > > > > > -lrte_security -lrte_compressdev -lrte_rawdev -lrte_mbuf
> > > > > > -lrte_kvargs -lrte_port -lrte_pci -lrte_ethdev -lrte_gro
> > > > > > -lrte_gso
> > > > > > -lrte_cryptodev -lrte_sched -lrte_latencystats -lrte_efd
> > > > > > -lrte_distributor -lrte_meter -lrte_acl -lrte_member
> > > > > > -lrte_cmdline
> > > > > > -lrte_lpm -lrte_kni -lrte_cfgfile -lrte_bitratestats
> > > > > > -lrte_timer
> > > > > > -lrte_flow_classify -lrte_mempool_bucket
> > > > > > -lrte_pmd_null_crypto
> > > > > > -lrte_pmd_failsafe -lrte_bus_ifpga -lrte_pmd_atlantic
> > > > > > -lrte_pmd_mlx4 -lrte_pmd_vmxnet3 -lrte_pmd_avp
> > > > > > -lrte_common_dpaax
> > > > > > -lrte_pmd_ena -lcrypto -lrte_bus_fslmc -ldl -lrte_pmd_avf
> > > > > > -lrte_pmd_crypto_scheduler -lrte_pmd_netvsc -lrte_pmd_vhost
> > > > > > -lrte_bus_dpaa -lrte_mempool_dpaa2 -lrte_common_octeontx
> > > > > > -lrte_pmd_liquidio -lrte_pmd_ifc -Wl,-Bdynamic -lnuma
> > > > > > -lrte_pmd_enic -lrte_common_cpt -pthread
> > > > > > -lrte_pmd_octeontx_crypto
> > > > > > -lrte_pmd_qat -lrte_bus_vmbus -lrte_pmd_null -lm
> > > > > > -lrte_pmd_dpaa
> > > > > > -lrte_bus_vdev -lrte_pmd_dpaa2 -lrte_pmd_skeleton_event
> > > > > > -lrte_pmd_af_packet -lrte_pmd_octeontx -lrte_pmd_thunderx
> > > > > > -lrte_pmd_ring -lrte_pmd_octeontx_event -lrte_pmd_sw_event
> > > > > > -lrte_pmd_ark -lrte_mempool_octeontx -lrte_pmd_ixgbe
> > > > > > -lrte_pmd_kni
> > > > > > -lrte_mempool_ring -lrte_pmd_virtio_crypto
> > > > > > -lrte_mempool_dpaa
> > > > > > -lrte_pmd_dpaa2_cmdif -lrte_bus_pci -lrte_pmd_opdl_event
> > > > > > -lrte_pmd_mlx5 -lrte_pmd_virtio -lrte_pmd_tap
> > > > > > -lrte_pmd_caam_jr
> > > > > > -lrte_pmd_dpaa2_sec -lrte_pmd_dpaa2_qdma -lrte_pmd_enetc
> > > > > > -lrte_pmd_sfc -lrte_pmd_bnxt -lrte_pmd_dpaa2_event
> > > > > > -lrte_pmd_cxgbe
> > > > > > -Wl,--whole-archive -Wl,--no- as-needed -lrte_pmd_e1000
> > > > > > -lrte_pmd_softnic -lrte_pmd_bond -lrte_pmd_fm10k
> > > > > > -lrte_pmd_i40e
> > > > > > -lrte_pmd_nfp -lrte_pmd_qede -Wl,--no- whole-archive
> > > > > > -lrte_pmd_axgbe -lrte_pmd_ccp -lrte_pmd_ifpga_rawdev
> > > > > > -lrte_pmd_bbdev_null -lrte_pmd_openssl -lrte_pmd_dsw_event
> > > > > > -lrte_pmd_dpaa_event -lrte_mempool_stack
> > > > > > -lrte_pmd_vdev_netvsc
> > > > > > -lrte_pmd_dpaa_sec -lrte_pmd_skeleton_rawdev
> > > > > > -lrte_pmd_octeontx_compress
> > > > > > 
> > > > > > You'll notice there's no mlx5 or mnl in that list. I was
> > > > > > using
> > > > > > 18.11-
> > > > > > rc2 since I cloned early yesterday. Perhaps meson
> > > > > > determined not
> > > > > > to put it in there for some reason?
> > > > > 
> > > > > Were mlx5/mnl found at meson configure time?
> > > > > 
> > > > > --
> > > > > Kind regards,
> > > > > Luca Boccassi
> > > > 
> > > > Hi Luca, yes, it was:
> > > > 
> > > > Library mnl found: YES
> > > > Library mlx4 found: YES
> > > > Library ibverbs found: YES
> > > > Compiler for C supports argument -Wextra: YES Compiler for C
> > > > supports
> > > > argument -std=c11: YES Compiler for C supports argument
> > > > -Wno-strict-prototypes: YES Compiler for C supports argument
> > > > -D_BSD_SOURCE: YES Compiler for C supports argument
> > > > -D_DEFAULT_SOURCE:
> > > > YES Compiler for C supports argument -D_XOPEN_SOURCE=600: YES
> > > > Checking
> > > > whether type "struct mlx4_wqe_lso_seg" has member
> > > > "mss_hdr_size": YES
> > > > Configuring mlx4_autoconf.h using configuration Library mnl
> > > > found: YES
> > > > Library mlx5 found: YES Library ibverbs found: YES ...
> > > > PKG_CONFIG_PATH=meson-private/ pkg-config --libs --static
> > > > libdpdk
> > > > -L/usr/local/lib/x86_64-linux-gnu -lrte_eventdev -lrte_power
> > > > -lrte_ip_frag -lrte_hash -lrte_pdump -lrte_eal -lrte_pipeline
> > > > -lrte_table -lrte_bbdev -lrte_bpf -lrte_vhost -lrte_metrics
> > > > -lrte_jobstats -lrte_net -lrte_reorder -lrte_ring -lrte_mempool
> > > > -lrte_security -lrte_compressdev -lrte_rawdev -lrte_mbuf
> > > > -lrte_kvargs
> > > > -lrte_port -lrte_pci -lrte_ethdev -lrte_gro -lrte_gso
> > > > -lrte_cryptodev
> > > > -lrte_sched -lrte_latencystats -lrte_efd -lrte_distributor
> > > > -lrte_meter
> > > > -lrte_acl -lrte_member -lrte_cmdline -lrte_lpm -lrte_kni
> > > > -lrte_cfgfile
> > > > -lrte_bitratestats -lrte_timer -lrte_flow_classify
> > > > -lrte_pmd_ccp
> > > > -lrte_mempool_bucket -lrte_pmd_failsafe -lrte_pmd_netvsc
> > > > -lrte_pmd_null_crypto -lrte_bus_ifpga -lrte_pmd_atlantic
> > > > -lrte_pmd_octeontx_event -lrte_pmd_avp -lrte_pmd_mlx4
> > > > -lrte_common_dpaax -lrte_pmd_skeleton_rawdev -lrte_pmd_ena
> > > > -lrte_pmd_opdl_event -lrte_bus_fslmc -lnuma -lrte_pmd_avf
> > > > -lrte_pmd_crypto_scheduler -lrte_pmd_vhost -lrte_bus_dpaa
> > > > -lrte_mempool_dpaa2 -lrte_common_octeontx -Wl,--no-as-needed
> > > > -lcrypto
> > > > -lrte_pmd_ifc -lrte_pmd_liquidio -lrte_pmd_enic
> > > > -lrte_common_cpt
> > > > -Wl,--no-whole-archive -lrte_bus_vmbus
> > > > -lrte_pmd_octeontx_crypto
> > > > -lrte_pmd_qat -lrte_pmd_ifpga_rawdev -lrte_pmd_dpaa
> > > > -lrte_bus_vdev
> > > > -lrte_pmd_bbdev_null -lrte_pmd_dpaa2 -lrte_pmd_skeleton_event
> > > > -lrte_pmd_ring -lrte_pmd_af_packet -lrte_pmd_thunderx
> > > > -lrte_pmd_dpaa_event -lrte_pmd_octeontx_compress
> > > > -lrte_pmd_dpaa_sec
> > > > -lrte_pmd_sw_event -Wl,--whole-archive -lrte_pmd_ark
> > > > -lrte_mempool_octeontx -lrte_pmd_ixgbe -lrte_mempool_ring
> > > > -lrte_pmd_kni -lrte_pmd_vmxnet3 -lrte_mempool_dpaa
> > > > -lrte_bus_pci
> > > > -lrte_pmd_dpaa2_cmdif -lrte_pmd_mlx5 -lrte_pmd_tap
> > > > -lrte_pmd_caam_jr
> > > > -lrte_pmd_dpaa2_sec -lm -lrte_pmd_dpaa2_qdma -lrte_pmd_enetc
> > > > -lrte_pmd_virtio -lrte_pmd_bnxt -lrte_pmd_dpaa2_event
> > > > -lrte_pmd_sfc
> > > > -lrte_pmd_cxgbe -pthread -lrte_pmd_e1000 -lrte_pmd_softnic -ldl
> > > > -lrte_pmd_null -lrte_pmd_bond -lrte_pmd_fm10k -lrte_pmd_i40e
> > > > -lrte_pmd_nfp -lrte_pmd_qede -lrte_pmd_axgbe -Wl,-Bdynamic
> > > > -lrte_pmd_openssl -lrte_pmd_octeontx -lrte_pmd_dsw_event
> > > > -lrte_mempool_stack -lrte_pmd_virtio_crypto
> > > > -lrte_pmd_vdev_netvsc
> > > 
> > > Is this with latest DPDK from git? because I see the exact same
> > > as Luca:
> > > 
> > > $ PKG_CONFIG_PATH=build/meson-private/ pkg-config --libs --static
> > 
> > libdpdk | grep mlx
> > > -L/usr/local/lib64 -lrte_telemetry -lrte_bpf -lrte_flow_classify
> > > -
> > 
> > lrte_pipeline -lrte_table -lrte_port -lrte_vhost -lrte_security -
> > lrte_sched -lrte_reorder -lrte_rawdev -lrte_pdump -lrte_power
> > -lrte_meter
> > -lrte_member -lrte_lpm -lrte_latencystats -lrte_kni -lrte_jobstats
> > -
> > lrte_ip_frag -lrte_gso -lrte_gro -lrte_eventdev -lrte_efd -
> > lrte_distributor -lrte_cryptodev -lrte_compressdev -lrte_cfgfile -
> > lrte_bitratestats -lrte_bbdev -lrte_acl -lrte_timer -lrte_hash -
> > lrte_metrics -lrte_pci -lrte_ethdev -lrte_net -lrte_mbuf
> > -lrte_mempool -
> > lrte_ring -lrte_eal -lrte_kvargs -lrte_cmdline -L/usr/local/lib64 -
> > lrte_kvargs -lrte_eal -lrte_ring -lrte_mempool -lrte_mbuf -lrte_pci
> > -
> > lrte_cryptodev -lrte_net -lrte_cmdline -lrte_ethdev -lrte_hash
> > -lrte_timer
> > -lrte_common_dpaax -lrte_eventdev -lrte_rawdev -lrte_bus_dpaa -
> > lrte_bus_fslmc -lrte_bus_pci -lrte_common_octeontx -lrte_bus_vdev -
> > lrte_meter -lrte_sched -lrte_ip_frag -lz -lrte_mempool_dpaa -
> > lrte_mempool_dpaa2 -lrte_vhost -lrte_security -lrte_kni -lmnl
> > -lmlx4 -
> > libverbs -lmnl -lmlx5 -libverbs -lrte_bus_vmbus
> > -lrte_mempool_octeontx -
> > lpcap -lrte_port -lrte_lpm -lrte_acl -lrte_table -lrte_pipeline
> > -lsze2 -
> > lrte_gso -lIPSec_MB -lIPSec_MB -lrte_common_cpt -lrte_reorder -
> > lrte_compressdev -lrte_pmd_dpaa -lrte_pmd_dpaa2 -lrte_pmd_dpaa2_sec
> > -
> > lrte_pmd_octeontx -lrte_bbdev -lrte_bus_ifpga -Wl,--whole-archive -
> > lrte_mempool_bucket -lrte_mempool_ring -lrte_mempool_stack -
> > lrte_pmd_af_packet -lrte_pmd_ark -lrte_pmd_atlantic -lrte_pmd_avf -
> > lrte_pmd_avp -lrte_pmd_axgbe -lrte_pmd_bond -lrte_pmd_bnx2x
> > -lrte_pmd_bnxt
> > -lrte_pmd_cxgbe -lrte_pmd_e1000 -lrte_pmd_ena -lrte_pmd_enetc -
> > lrte_pmd_enic -lrte_pmd_failsafe -lrte_pmd_fm10k -lrte_pmd_i40e -
> > lrte_pmd_ifc -lrte_pmd_ixgbe -lrte_pmd_kmod -lrte_pmd_kni -
> > lrte_pmd_liquidio -lrte_pmd_mlx4 -lrte_pmd_mlx5 -lrte_pmd_netvsc -
> > lrte_pmd_nfp -lrte_pmd_null -lrte_pmd_pcap -lrte_pmd_qede
> > -lrte_pmd_ring -
> > lrte_pmd_sfc -lrte_pmd_softnic -lrte_pmd_szedata2 -lrte_pmd_tap -
> > lrte_pmd_thunderx -lrte_pmd_vdev_netvsc -lrte_pmd_vhost
> > -lrte_pmd_virtio -
> > lrte_pmd_vmxnet3 -lrte_pmd_aesni_gcm -lrte_pmd_aesni_mb
> > -lrte_pmd_caam_jr
> > -lrte_pmd_ccp -lrte_pmd_dpaa_sec -lrte_pmd_null_crypto -
> > lrte_pmd_octeontx_crypto -lrte_pmd_openssl
> > -lrte_pmd_crypto_scheduler -
> > lrte_pmd_virtio_crypto -lrte_pmd_octeontx_compress -lrte_pmd_qat -
> > lrte_pmd_zlib -lrte_pmd_dpaa_event -lrte_pmd_dpaa2_event -
> > lrte_pmd_octeontx_event -lrte_pmd_opdl_event
> > -lrte_pmd_skeleton_event -
> > lrte_pmd_sw_event -lrte_pmd_dsw_event -lrte_pmd_bbdev_null -
> > lrte_pmd_skeleton_rawdev -lrte_pmd_dpaa2_cmdif -lrte_pmd_dpaa2_qdma
> > -
> > lrte_pmd_ifpga_rawdev -lrte_pmd_ioat_copy -Wl,--no-whole-archive
> > -Wl,-
> > Bdynamic -Wl,--no-as-needed -pthread -lm -ldl -lnuma -lbsd -lpcap
> > -lcrypto
> > -lcrypto -lz -lcrypto -ldl -pthread -lz
> > 
> > Hi Bruce, I tried with rc3 and a new clone from right now, and get
> > the
> > same results:
> > 
> > $ meson build
> > The Meson build system
> > Version: 0.45.1
> > Source dir: /home/cburdick/dpdk
> > Build dir: /home/cburdick/dpdk/build
> > Build type: native build
> > Project name: DPDK
> > Native C compiler: cc (gcc 7.3.0 "cc (Ubuntu 7.3.0-27ubuntu1~18.04)
> > 7.3.0")
> > Build machine cpu family: x86_64
> > Build machine cpu: x86_64
> > Library numa found: YES
> > Has header "numaif.h": YES
> > Library bsd found: NO
> > Checking for size of "void *": 8
> > Compiler for C supports argument -Wsign-compare: YES
> > Compiler for C supports argument -Wcast-qual: YES
> > Compiler for C supports argument -Wno-address-of-packed-member: YES
> > Fetching value of define "__SSE4_2__": 1
> > Fetching value of define "__AES__": 1
> > Fetching value of define "__PCLMUL__": 1
> > Fetching value of define "__AVX__": 1
> > Fetching value of define "__AVX2__": 1
> > Fetching value of define "__AVX512F__":
> > Compiler for C supports argument -Wno-format-truncation: YES
> > Checking for size of "void *": 8
> > Has header "linux/userfaultfd.h": YES
> > Checking for size of "void *": 8
> > Library elf found: NO
> > Library jansson found: NO
> > Program gen-pmdinfo-cfile.sh found: YES
> > (/home/cburdick/dpdk/buildtools/gen-pmdinfo-cfile.sh)
> > Compiler for C supports argument -Wno-format-truncation: YES
> > Library libmusdk found: NO
> > Compiler for C supports argument -Wno-cast-qual: YES
> > Compiler for C supports argument -Wno-pointer-to-int-cast: YES
> > Library z found: NO
> > Compiler for C supports argument -Wno-uninitialized: YES
> > Compiler for C supports argument -Wno-unused-parameter: YES
> > Compiler for C supports argument -Wno-unused-variable: YES
> > Compiler for C supports argument -Wno-misleading-indentation: YES
> > Compiler for C supports argument -Wno-implicit-fallthrough: YES
> > Checking for size of "void *": 8
> > Compiler for C supports argument -Wno-unused-parameter: YES
> > Compiler for C supports argument -Wno-unused-value: YES
> > Compiler for C supports argument -Wno-strict-aliasing: YES
> > Compiler for C supports argument -Wno-format-extra-args: YES
> > Compiler for C supports argument -Wno-unused-variable: YES
> > Compiler for C supports argument -Wno-missing-field-initializers:
> > YES
> > Compiler for C supports argument -Wno-sign-compare: YES
> > Compiler for C supports argument -Wno-unused-value: YES
> > Compiler for C supports argument -Wno-format: YES
> > Compiler for C supports argument -Wno-error=format-security: YES
> > Compiler for C supports argument -Wno-strict-aliasing: YES
> > Compiler for C supports argument -Wno-unused-but-set-variable: YES
> > Compiler for C supports argument -Wno-unused-value: YES
> > Compiler for C supports argument -Wno-unused-but-set-variable: YES
> > Library mnl found: YES
> > Library mlx4 found: YES
> > Library ibverbs found: YES
> > Compiler for C supports argument -Wextra: YES
> > Compiler for C supports argument -std=c11: YES
> > Compiler for C supports argument -Wno-strict-prototypes: YES
> > Compiler for C supports argument -D_BSD_SOURCE: YES
> > Compiler for C supports argument -D_DEFAULT_SOURCE: YES
> > Compiler for C supports argument -D_XOPEN_SOURCE=600: YES
> > Checking whether type "struct mlx4_wqe_lso_seg" has member
> > "mss_hdr_size":
> > YES
> > Configuring mlx4_autoconf.h using configuration
> > Library mnl found: YES
> > Library mlx5 found: YES
> > Library ibverbs found: YES
> > Compiler for C supports argument -Wextra: YES
> > Compiler for C supports argument -std=c11: YES
> > Compiler for C supports argument -Wno-strict-prototypes: YES
> > Compiler for C supports argument -D_BSD_SOURCE: YES
> > Compiler for C supports argument -D_DEFAULT_SOURCE: YES
> > Compiler for C supports argument -D_XOPEN_SOURCE=600: YES
> > Header <infiniband/mlx5dv.h> has symbol
> > "MLX5DV_CQE_RES_FORMAT_CSUM_STRIDX": YES
> > Header <infiniband/mlx5dv.h> has symbol
> > "MLX5DV_CONTEXT_MASK_TUNNEL_OFFLOADS": YES
> > Header <infiniband/mlx5dv.h> has symbol
> > "MLX5DV_CONTEXT_FLAGS_MPW_ALLOWED": YES
> > Header <infiniband/mlx5dv.h> has symbol
> > "MLX5DV_CONTEXT_FLAGS_CQE_128B_COMP": YES
> > Header <infiniband/mlx5dv.h> has symbol
> > "MLX5DV_CQ_INIT_ATTR_FLAGS_CQE_PAD": YES
> > Header <infiniband/mlx5dv.h> has symbol
> > "mlx5dv_create_flow_action_packet_reformat": NO
> > Header <infiniband/verbs.h> has symbol "IBV_FLOW_SPEC_MPLS": YES
> > Header <infiniband/verbs.h> has symbol
> > "IBV_WQ_FLAG_RX_END_PADDING": NO
> > Header <linux/ethtool.h> has symbol "SUPPORTED_40000baseKR4_Full":
> > YES
> > Header <linux/ethtool.h> has symbol "SUPPORTED_40000baseCR4_Full":
> > YES
> > Header <linux/ethtool.h> has symbol "SUPPORTED_40000baseSR4_Full":
> > YES
> > Header <linux/ethtool.h> has symbol "SUPPORTED_40000baseLR4_Full":
> > YES
> > Header <linux/ethtool.h> has symbol "SUPPORTED_56000baseKR4_Full":
> > YES
> > Header <linux/ethtool.h> has symbol "SUPPORTED_56000baseCR4_Full":
> > YES
> > Header <linux/ethtool.h> has symbol "SUPPORTED_56000baseSR4_Full":
> > YES
> > Header <linux/ethtool.h> has symbol "SUPPORTED_56000baseLR4_Full":
> > YES
> > Header <linux/ethtool.h> has symbol
> > "ETHTOOL_LINK_MODE_25000baseCR_Full_BIT": YES
> > Header <linux/ethtool.h> has symbol
> > "ETHTOOL_LINK_MODE_50000baseCR2_Full_BIT": YES
> > Header <linux/ethtool.h> has symbol
> > "ETHTOOL_LINK_MODE_100000baseKR4_Full_BIT": YES
> > Header <linux/if_link.h> has symbol "IFLA_PHYS_SWITCH_ID": YES
> > Header <linux/if_link.h> has symbol "IFLA_PHYS_PORT_NAME": YES
> > Header <linux/if_link.h> has symbol "IFLA_VXLAN_COLLECT_METADATA":
> > YES
> > Header <linux/rtnetlink.h> has symbol "TCA_CHAIN": YES
> > Header <linux/pkt_cls.h> has symbol "TCA_FLOWER_ACT": YES
> > Header <linux/pkt_cls.h> has symbol "TCA_FLOWER_FLAGS": YES
> > Header <linux/pkt_cls.h> has symbol "TCA_FLOWER_KEY_ETH_TYPE": YES
> > Header <linux/pkt_cls.h> has symbol "TCA_FLOWER_KEY_ETH_DST": YES
> > Header <linux/pkt_cls.h> has symbol "TCA_FLOWER_KEY_ETH_DST_MASK":
> > YES
> > Header <linux/pkt_cls.h> has symbol "TCA_FLOWER_KEY_ETH_SRC": YES
> > Header <linux/pkt_cls.h> has symbol "TCA_FLOWER_KEY_ETH_SRC_MASK":
> > YES
> > Header <linux/pkt_cls.h> has symbol "TCA_FLOWER_KEY_IP_PROTO": YES
> > Header <linux/pkt_cls.h> has symbol "TCA_FLOWER_KEY_IPV4_SRC": YES
> > Header <linux/pkt_cls.h> has symbol "TCA_FLOWER_KEY_IPV4_SRC_MASK":
> > YES
> > Header <linux/pkt_cls.h> has symbol "TCA_FLOWER_KEY_IPV4_DST": YES
> > Header <linux/pkt_cls.h> has symbol "TCA_FLOWER_KEY_IPV4_DST_MASK":
> > YES
> > Header <linux/pkt_cls.h> has symbol "TCA_FLOWER_KEY_IPV6_SRC": YES
> > Header <linux/pkt_cls.h> has symbol "TCA_FLOWER_KEY_IPV6_SRC_MASK":
> > YES
> > Header <linux/pkt_cls.h> has symbol "TCA_FLOWER_KEY_IPV6_DST": YES
> > Header <linux/pkt_cls.h> has symbol "TCA_FLOWER_KEY_IPV6_DST_MASK":
> > YES
> > Header <linux/pkt_cls.h> has symbol "TCA_FLOWER_KEY_TCP_SRC": YES
> > Header <linux/pkt_cls.h> has symbol "TCA_FLOWER_KEY_TCP_SRC_MASK":
> > YES
> > Header <linux/pkt_cls.h> has symbol "TCA_FLOWER_KEY_TCP_DST": YES
> > Header <linux/pkt_cls.h> has symbol "TCA_FLOWER_KEY_TCP_DST_MASK":
> > YES
> > Header <linux/pkt_cls.h> has symbol "TCA_FLOWER_KEY_UDP_SRC": YES
> > Header <linux/pkt_cls.h> has symbol "TCA_FLOWER_KEY_UDP_SRC_MASK":
> > YES
> > Header <linux/pkt_cls.h> has symbol "TCA_FLOWER_KEY_UDP_DST": YES
> > Header <linux/pkt_cls.h> has symbol "TCA_FLOWER_KEY_UDP_DST_MASK":
> > YES
> > Header <linux/pkt_cls.h> has symbol "TCA_FLOWER_KEY_VLAN_ID": YES
> > Header <linux/pkt_cls.h> has symbol "TCA_FLOWER_KEY_VLAN_PRIO": YES
> > Header <linux/pkt_cls.h> has symbol "TCA_FLOWER_KEY_VLAN_ETH_TYPE":
> > YES
> > Header <linux/pkt_cls.h> has symbol "TCA_FLOWER_KEY_TCP_FLAGS": YES
> > Header <linux/pkt_cls.h> has symbol
> > "TCA_FLOWER_KEY_TCP_FLAGS_MASK": YES
> > Header <linux/pkt_cls.h> has symbol "TC_ACT_GOTO_CHAIN": YES
> > Header <linux/tc_act/tc_vlan.h> has symbol
> > "TCA_VLAN_PUSH_VLAN_PRIORITY":
> > YES
> > Header <linux/pkt_cls.h> has symbol "TCA_FLOWER_KEY_ENC_KEY_ID":
> > YES
> > Header <linux/pkt_cls.h> has symbol "TCA_FLOWER_KEY_ENC_IPV4_SRC":
> > YES
> > Header <linux/pkt_cls.h> has symbol
> > "TCA_FLOWER_KEY_ENC_IPV4_SRC_MASK":
> > YES
> > Header <linux/pkt_cls.h> has symbol "TCA_FLOWER_KEY_ENC_IPV4_DST":
> > YES
> > Header <linux/pkt_cls.h> has symbol
> > "TCA_FLOWER_KEY_ENC_IPV4_DST_MASK":
> > YES
> > Header <linux/pkt_cls.h> has symbol "TCA_FLOWER_KEY_ENC_IPV6_SRC":
> > YES
> > Header <linux/pkt_cls.h> has symbol
> > "TCA_FLOWER_KEY_ENC_IPV6_SRC_MASK":
> > YES
> > Header <linux/pkt_cls.h> has symbol "TCA_FLOWER_KEY_ENC_IPV6_DST":
> > YES
> > Header <linux/pkt_cls.h> has symbol
> > "TCA_FLOWER_KEY_ENC_IPV6_DST_MASK":
> > YES
> > Header <linux/pkt_cls.h> has symbol
> > "TCA_FLOWER_KEY_ENC_UDP_SRC_PORT": YES
> > Header <linux/pkt_cls.h> has symbol
> > "TCA_FLOWER_KEY_ENC_UDP_SRC_PORT_MASK": YES
> > Header <linux/pkt_cls.h> has symbol
> > "TCA_FLOWER_KEY_ENC_UDP_DST_PORT": YES
> > Header <linux/pkt_cls.h> has symbol
> > "TCA_FLOWER_KEY_ENC_UDP_DST_PORT_MASK": YES
> > Header <linux/tc_act/tc_tunnel_key.h> has symbol
> > "TCA_ACT_TUNNEL_KEY": YES
> > Header <linux/tc_act/tc_tunnel_key.h> has symbol
> > "TCA_TUNNEL_KEY_ENC_DST_PORT": YES
> > Header <linux/tc_act/tc_tunnel_key.h> has symbol
> > "TCA_TUNNEL_KEY_NO_CSUM":
> > YES
> > Header <linux/tc_act/tc_pedit.h> has symbol
> > "TCA_PEDIT_KEY_EX_HDR_TYPE_UDP": YES
> > Header <rdma/rdma_netlink.h> has symbol "RDMA_NL_NLDEV": YES
> > Header <rdma/rdma_netlink.h> has symbol "RDMA_NLDEV_CMD_GET": YES
> > Header <rdma/rdma_netlink.h> has symbol "RDMA_NLDEV_CMD_PORT_GET":
> > YES
> > Header <rdma/rdma_netlink.h> has symbol
> > "RDMA_NLDEV_ATTR_DEV_INDEX": YES
> > Header <rdma/rdma_netlink.h> has symbol "RDMA_NLDEV_ATTR_DEV_NAME":
> > YES
> > Header <rdma/rdma_netlink.h> has symbol
> > "RDMA_NLDEV_ATTR_PORT_INDEX": YES
> > Header <rdma/rdma_netlink.h> has symbol
> > "RDMA_NLDEV_ATTR_NDEV_INDEX": NO
> > Checking whether type "struct mlx5dv_sw_parsing_caps" has member
> > "sw_parsing_offloads": YES
> > Checking whether type "struct ibv_counter_set_init_attr" has member
> > "counter_set_id": YES
> > Checking whether type "struct ibv_counters_init_attr" has member
> > "comp_mask": NO
> > Configuring mlx5_autoconf.h using configuration
> > Library libmusdk found: NO
> > Library libmusdk found: NO
> > Library pcap found: NO
> > Compiler for C supports argument -Wno-unused-parameter: YES
> > Compiler for C supports argument -Wno-sign-compare: YES
> > Compiler for C supports argument -Wno-missing-prototypes: YES
> > Compiler for C supports argument -Wno-cast-qual: YES
> > Compiler for C supports argument -Wno-unused-function: YES
> > Compiler for C supports argument -Wno-unused-variable: YES
> > Compiler for C supports argument -Wno-strict-aliasing: YES
> > Compiler for C supports argument -Wno-missing-prototypes: YES
> > Compiler for C supports argument -Wno-unused-value: YES
> > Compiler for C supports argument -Wno-format-nonliteral: YES
> > Compiler for C supports argument -Wno-shift-negative-value: YES
> > Compiler for C supports argument -Wno-unused-but-set-variable: YES
> > Compiler for C supports argument -Wno-missing-declarations: YES
> > Compiler for C supports argument -Wno-maybe-uninitialized: YES
> > Compiler for C supports argument -Wno-strict-prototypes: YES
> > Compiler for C supports argument -Wno-shift-negative-value: YES
> > Compiler for C supports argument -Wno-implicit-fallthrough: YES
> > Compiler for C supports argument -Wno-format-extra-args: YES
> > Compiler for C supports argument -Wno-visibility: YES
> > Compiler for C supports argument -Wno-empty-body: YES
> > Compiler for C supports argument -Wno-invalid-source-encoding: YES
> > Compiler for C supports argument -Wno-sometimes-uninitialized: YES
> > Compiler for C supports argument -Wno-pointer-bool-conversion: YES
> > Checking for size of "void *": 8
> > Compiler for C supports argument -Wno-strict-aliasing: YES
> > Compiler for C supports argument -Wextra: YES
> > Compiler for C supports argument -Wdisabled-optimization: YES
> > Compiler for C supports argument -Waggregate-return: YES
> > Compiler for C supports argument -Wnested-externs: YES
> > Compiler for C supports argument -Wbad-function-cast: YES
> > Compiler for C supports argument -Wno-sign-compare: YES
> > Compiler for C supports argument -Wno-unused-parameter: YES
> > Compiler for C supports argument -Wno-unused-variable: YES
> > Compiler for C supports argument -Wno-empty-body: YES
> > Compiler for C supports argument -Wno-unused-but-set-variable: YES
> > Library sze2 found: NO
> > Header <linux/pkt_cls.h> has symbol "TCA_FLOWER_UNSPEC": YES
> > Header <linux/pkt_cls.h> has symbol "TCA_FLOWER_KEY_VLAN_PRIO": YES
> > Header <linux/pkt_cls.h> has symbol "TCA_BPF_UNSPEC": YES
> > Header <linux/pkt_cls.h> has symbol "TCA_BPF_FD": YES
> > Header <linux/tc_act/tc_bpf.h> has symbol "TCA_ACT_BPF_UNSPEC": YES
> > Header <linux/tc_act/tc_bpf.h> has symbol "TCA_ACT_BPF_FD": YES
> > Configuring tap_autoconf.h using configuration
> > Compiler for C supports argument -fno-prefetch-loop-arrays: YES
> > Compiler for C supports argument -Wno-maybe-uninitialized: YES
> > Compiler for C supports argument -Wall: YES
> > Compiler for C supports argument -Wextra: YES
> > Compiler for C supports argument -D_BSD_SOURCE: YES
> > Compiler for C supports argument -D_DEFAULT_SOURCE: YES
> > Compiler for C supports argument -D_XOPEN_SOURCE=600: YES
> > Compiler for C supports argument -Wno-unused-parameter: YES
> > Compiler for C supports argument -Wno-unused-value: YES
> > Compiler for C supports argument -Wno-strict-aliasing: YES
> > Compiler for C supports argument -Wno-format-extra-args: YES
> > Library IPSec_MB found: NO
> > Library IPSec_MB found: NO
> > Found pkg-config: /usr/bin/pkg-config (0.29.1)
> > Native dependency libcrypto found: YES 1.1.0g
> > Library libsso_kasumi found: NO
> > Library libmusdk found: NO
> > Dependency libcrypto found: YES (cached)
> > Dependency libcrypto found: YES (cached)
> > Library libsso_zuc found: NO
> > Dependency libisal found: NO
> > Dependency zlib found: NO
> > Compiler for C supports argument -Wno-sign-compare: YES
> > Compiler for C supports argument -Wno-unused-value: YES
> > Compiler for C supports argument -Wno-format: YES
> > Compiler for C supports argument -Wno-error=format-security: YES
> > Compiler for C supports argument -Wno-strict-aliasing: YES
> > Compiler for C supports argument -Wno-unused-but-set-variable: YES
> > Library execinfo found: NO
> > Compiler for C supports argument -Wno-format-truncation: YES
> > Dependency zlib found: NO
> > Library execinfo found: NO
> > Program doxygen found: NO
> > Program sphinx-build found: NO
> > kernel/linux/kni/meson.build:16: WARNING: Passed invalid keyword
> > argument
> > "console".
> > WARNING: This will become a hard error in the future.
> > WARNING: Unknown keyword arguments in target rte_kni: console
> > Configuring rte_build_config.h using configuration
> > Program buildtools/symlink-drivers-solibs.sh found: YES (/bin/sh
> > /home/cburdick/dpdk/buildtools/symlink-drivers-solibs.sh)
> > Message:
> > =================
> > Libraries Enabled
> > =================
> > 
> > libs:
> > \tcompat, cmdline, kvargs, eal, ring, mempool, mbuf, net,
> > \tethdev, pci, metrics, hash, timer, acl, bbdev, bitratestats,
> > \tcfgfile, compressdev, cryptodev, distributor, efd, eventdev, gro,
> > gso,
> > \tip_frag, jobstats, kni, latencystats, lpm, member, meter, power,
> > \tpdump, rawdev, reorder, sched, security, vhost, port, table,
> > \tpipeline, flow_classify, bpf,
> > 
> > Build targets in project: 411
> > Found ninja-1.8.2 at /usr/bin/ninja
> > [cburdick@dev01 ~/dpdk] (master)
> > $ cd build
> > [cburdick@dev01 ~/dpdk/build] (master)
> > $ ninja
> > [1428/1431] Generating igb_uio with a custom command.
> > make: Entering directory '/usr/src/linux-headers-4.15.0-20-generic'
> > Makefile:976: "Cannot use CONFIG_STACK_VALIDATION=y, please install
> > libelf-dev, libelf-devel or elfutils-libelf-devel"
> >   CC [M]  /home/cburdick/dpdk/build/kernel/linux/igb_uio/igb_uio.o
> >   Building modules, stage 2.
> >   MODPOST 1 modules
> >  
> > CC      /home/cburdick/dpdk/build/kernel/linux/igb_uio/igb_uio.mod.
> > o
> >   LD [M]  /home/cburdick/dpdk/build/kernel/linux/igb_uio/igb_uio.ko
> > make: Leaving directory '/usr/src/linux-headers-4.15.0-20-generic'
> > [1431/1431] Generating rte_kni with a custom command.
> > make: Entering directory '/usr/src/linux-headers-4.15.0-20-generic'
> > Makefile:976: "Cannot use CONFIG_STACK_VALIDATION=y, please install
> > libelf-dev, libelf-devel or elfutils-libelf-devel"
> >   CC [M]  /home/cburdick/dpdk/build/kernel/linux/kni/kni_net.o
> >   CC [M]  /home/cburdick/dpdk/build/kernel/linux/kni/kni_misc.o
> >   CC [M]  /home/cburdick/dpdk/build/kernel/linux/kni/kni_ethtool.o
> >   CC [M]
> > /home/cburdick/dpdk/build/kernel/linux/kni/ethtool/ixgbe/ixgbe_etht
> > ool.o
> >   CC [M]
> > /home/cburdick/dpdk/build/kernel/linux/kni/ethtool/ixgbe/ixgbe_8259
> > 9.o
> >   CC [M]
> > /home/cburdick/dpdk/build/kernel/linux/kni/ethtool/ixgbe/ixgbe_api.
> > o
> >   CC [M]
> > /home/cburdick/dpdk/build/kernel/linux/kni/ethtool/ixgbe/ixgbe_x540
> > .o
> >   CC [M]
> > /home/cburdick/dpdk/build/kernel/linux/kni/ethtool/ixgbe/ixgbe_comm
> > on.o
> >   CC [M]
> > /home/cburdick/dpdk/build/kernel/linux/kni/ethtool/ixgbe/ixgbe_phy.
> > o
> >   CC [M]
> > /home/cburdick/dpdk/build/kernel/linux/kni/ethtool/ixgbe/ixgbe_8259
> > 8.o
> >   CC [M]
> > /home/cburdick/dpdk/build/kernel/linux/kni/ethtool/ixgbe/ixgbe_main
> > .o
> >   CC [M]
> > /home/cburdick/dpdk/build/kernel/linux/kni/ethtool/ixgbe/kcompat.o
> >   CC [M]
> > /home/cburdick/dpdk/build/kernel/linux/kni/ethtool/igb/e1000_82575.
> > o
> >   CC [M]
> > /home/cburdick/dpdk/build/kernel/linux/kni/ethtool/igb/e1000_i210.o
> >   CC [M]
> > /home/cburdick/dpdk/build/kernel/linux/kni/ethtool/igb/e1000_mbx.o
> >   CC [M]
> > /home/cburdick/dpdk/build/kernel/linux/kni/ethtool/igb/e1000_api.o
> >   CC [M]
> > /home/cburdick/dpdk/build/kernel/linux/kni/ethtool/igb/igb_main.o
> >   CC [M]
> > /home/cburdick/dpdk/build/kernel/linux/kni/ethtool/igb/igb_vmdq.o
> >   CC [M]
> > /home/cburdick/dpdk/build/kernel/linux/kni/ethtool/igb/e1000_manage
> > .o
> >   CC [M]
> > /home/cburdick/dpdk/build/kernel/linux/kni/ethtool/igb/igb_ethtool.
> > o
> >   CC [M]
> > /home/cburdick/dpdk/build/kernel/linux/kni/ethtool/igb/igb_param.o
> >   CC [M]
> > /home/cburdick/dpdk/build/kernel/linux/kni/ethtool/igb/e1000_mac.o
> >   CC [M]
> > /home/cburdick/dpdk/build/kernel/linux/kni/ethtool/igb/e1000_phy.o
> >   CC [M]
> > /home/cburdick/dpdk/build/kernel/linux/kni/ethtool/igb/e1000_nvm.o
> >   LD [M]  /home/cburdick/dpdk/build/kernel/linux/kni/rte_kni.o
> >   Building modules, stage 2.
> >   MODPOST 1 modules
> >   CC      /home/cburdick/dpdk/build/kernel/linux/kni/rte_kni.mod.o
> >   LD [M]  /home/cburdick/dpdk/build/kernel/linux/kni/rte_kni.ko
> > make: Leaving directory '/usr/src/linux-headers-4.15.0-20-generic'
> > [cburdick@dev01 ~/dpdk/build] (master)
> > $ PKG_CONFIG_PATH=meson-private/ pkg-config --libs --static
> > libdpdk|grep
> > mlx
> > -L/usr/local/lib/x86_64-linux-gnu -lrte_flow_classify
> > -lrte_eventdev -
> > lrte_ip_frag -lrte_power -lrte_hash -lrte_pdump -lrte_pipeline
> > -lrte_table
> > -lrte_mbuf -lrte_bbdev -lrte_bpf -lrte_vhost -lrte_metrics
> > -lrte_mempool -
> > lrte_jobstats -lrte_reorder -lrte_net -lrte_security -lrte_eal
> > -lrte_ring
> > -lrte_ethdev -lrte_compressdev -lrte_rawdev -lrte_kvargs -lrte_pci
> > -
> > lrte_cfgfile -lrte_gro -lrte_gso -lrte_cryptodev -lrte_latencystats
> > -
> > lrte_sched -lrte_efd -lrte_distributor -lrte_acl -lrte_member -
> > lrte_cmdline -lrte_lpm -lrte_meter -lrte_kni -lrte_bitratestats -
> > lrte_timer -lrte_port -lrte_mempool_bucket -lrte_pmd_vdev_netvsc -
> > lrte_pmd_ark -lrte_pmd_failsafe -lrte_pmd_netvsc
> > -lrte_pmd_null_crypto -
> > lrte_bus_ifpga -lrte_common_dpaax -lrte_pmd_ixgbe
> > -lrte_mempool_ring -
> > lrte_pmd_kni -lrte_pmd_vmxnet3 -lrte_pmd_mlx4 -lrte_pmd_virtio
> > -Wl,--no-
> > as-needed -lrte_mempool_dpaa -lrte_pmd_ena -lrte_bus_fslmc
> > -lrte_pmd_avf -
> > lrte_pmd_dpaa2_sec -lrte_common_octeontx -lrte_pmd_skeleton_rawdev
> > -
> > lrte_pmd_crypto_scheduler -lrte_pmd_dpaa2_qdma -lrte_pmd_vhost -ldl
> > -
> > lrte_bus_dpaa -lrte_pmd_fm10k -lrte_pmd_bnxt -lrte_pmd_qat
> > -lrte_pmd_bond
> > -lrte_pmd_axgbe -lrte_pmd_dpaa2 -lrte_pmd_skeleton_event -
> > lrte_pmd_dpaa_event -lrte_mempool_stack -pthread -lrte_pmd_ccp -
> > lrte_pmd_octeontx_compress -lrte_pmd_sw_event
> > -lrte_mempool_octeontx -Wl,-
> > Bdynamic -lrte_pmd_dpaa_sec -lrte_pmd_atlantic
> > -lrte_pmd_octeontx_event -
> > lrte_pmd_avp -lrte_bus_pci -lrte_pmd_dpaa2_cmdif -lrte_pmd_mlx5 -
> > lrte_pmd_opdl_event -lrte_pmd_tap -lrte_pmd_caam_jr -lrte_pmd_sfc
> > -lcrypto
> > -lrte_pmd_enetc -lrte_mempool_dpaa2 -lrte_pmd_dpaa2_event
> > -lrte_pmd_ifc -
> > lrte_pmd_liquidio -lrte_pmd_cxgbe -lm -lrte_pmd_enic -lrte_bus_vdev
> > -
> > lrte_pmd_e1000 -lrte_pmd_softnic -lrte_pmd_ifpga_rawdev
> > -lrte_bus_vmbus -
> > lrte_pmd_octeontx_crypto -lrte_pmd_null -lnuma -lrte_common_cpt -
> > lrte_pmd_nfp -lrte_pmd_qede -lrte_pmd_i40e -lrte_pmd_dpaa -Wl,
> > --whole-
> > archive -lrte_pmd_bbdev_null -lrte_pmd_af_packet -lrte_pmd_thunderx
> > -
> > lrte_pmd_openssl -lrte_pmd_octeontx -lrte_pmd_dsw_event -Wl,--no-
> > whole-
> > archive -lrte_pmd_ring -lrte_pmd_virtio_crypto
> 
> That is strange. Can you try one last thing - can you update meson
> with "pip3 install --upgrade meson" and see if that makes any
> difference? [If you are using your distro's meson from /usr/bin right
> now, you'll probably also need to run "hash meson" afterwards too].
> Perhaps we have a hidden dependency on later meson versions or
> something like that.
> 
> /Bruce

We do - I can reproduce the same issue with 0.45.1, while normally I
run 0.47.2. Should we bump the minimum version? Or simply document it?

-- 
Kind regards,
Luca Boccassi

Re: [dpdk-dev] [PATCH 1/1] eal: Don't fail secondary if primary is missing tailqs

[Bruce Richardson]

On Thu, Nov 15, 2018 at 05:05:16PM +0000, Luca Boccassi wrote:
> On Thu, 2018-11-15 at 17:01 +0000, Richardson, Bruce wrote:
> > > -----Original Message-----
> > > From: Burdick, Cliff [mailto:Cliff.Burdick@viasat.com]
> > > Sent: Thursday, November 15, 2018 4:55 PM
> > > To: Richardson, Bruce <bruce.richardson@intel.com>
> > > Cc: Luca Boccassi <bluca@debian.org>; Thomas Monjalon
> > > <thomas@monjalon.net>; Burakov, Anatoly <anatoly.burakov@intel.com>
> > > ;
> > > dev@dpdk.org
> > > Subject: RE: [dpdk-dev] [PATCH 1/1] eal: Don't fail secondary if
> > > primary
> > > is missing tailqs
> > > 
> > > 
> > > 
> > > -----Original Message-----
> > > From: Bruce Richardson [mailto:bruce.richardson@intel.com]
> > > Sent: Thursday, November 15, 2018 8:41 AM
> > > To: Burdick, Cliff
> > > Cc: Luca Boccassi; Thomas Monjalon; Burakov, Anatoly; dev@dpdk.org
> > > Subject: Re: [dpdk-dev] [PATCH 1/1] eal: Don't fail secondary if
> > > primary
> > > is missing tailqs
> > > 
> > > > On Thu, Nov 15, 2018 at 04:15:36PM +0000, Burdick, Cliff wrote:
> > > > > 
> > > > > 
> > > > > -----Original Message-----
> > > > > From: Luca Boccassi [mailto:bluca@debian.org]
> > > > > Sent: Thursday, November 15, 2018 1:33 AM
> > > > > To: Burdick, Cliff; Bruce Richardson
> > > > > Cc: Thomas Monjalon; Burakov, Anatoly; dev@dpdk.org
> > > > > Subject: Re: [dpdk-dev] [PATCH 1/1] eal: Don't fail secondary
> > > > > if
> > > > > primary is missing tailqs
> > > > > 
> > > > > > On Wed, 2018-11-14 at 18:24 +0000, Burdick, Cliff wrote:
> > > > > > > 
> > > > > > > -----Original Message-----
> > > > > > > From: Luca Boccassi [mailto:bluca@debian.org]
> > > > > > > Sent: Wednesday, November 14, 2018 10:15 AM
> > > > > > > To: Burdick, Cliff; Bruce Richardson
> > > > > > > Cc: Thomas Monjalon; Burakov, Anatoly; dev@dpdk.org
> > > > > > > Subject: Re: [dpdk-dev] [PATCH 1/1] eal: Don't fail
> > > > > > > secondary if
> > > > > > > primary is missing tailqs
> > > > > > > 
> > > > > > > > On Wed, 2018-11-14 at 17:40 +0000, Burdick, Cliff wrote:
> > > > > > > > > 
> > > > > > > > > -----Original Message-----
> > > > > > > > > From: Bruce Richardson [mailto:bruce.richardson@intel.c
> > > > > > > > > om]
> > > > > > > > > Sent: Wednesday, November 14, 2018 3:48 AM
> > > > > > > > > To: Burdick, Cliff
> > > > > > > > > Cc: Thomas Monjalon; Burakov, Anatoly; dev@dpdk.org
> > > > > > > > > Subject: Re: [dpdk-dev] [PATCH 1/1] eal: Don't fail
> > > > > > > > > secondary
> > > > > > > > > if primary is missing tailqs
> > > > > > > > > 
> > > > > > > > > On Tue, Nov 13, 2018 at 11:42:51PM +0000, Burdick,
> > > > > > > > > Cliff
> > > 
> > > wrote:
> > > > > > > > > > > 
> > > > > > > > > > > ________________________________________
> > > > > > > > > > > From: Thomas Monjalon [thomas@monjalon.net]
> > > > > > > > > > > Sent: Tuesday, November 13, 2018 2:18 PM
> > > > > > > > > > > To: Burdick, Cliff
> > > > > > > > > > > Cc: Burakov, Anatoly; dev@dpdk.org;
> > > > > > > > > > > bruce.richardson@intel.co m
> > > > > > > > > > > Subject: Re: [dpdk-dev] [PATCH 1/1] eal: Don't fail
> > > > > > > > > > > secondary if primary is missing tailqs
> > > > > > > > > > > 
> > > > > > > > > > > 13/11/2018 23:08, Burdick, Cliff:
> > > > > > > > > > > > From: Thomas Monjalon [mailto:thomas@monjalon.net
> > > > > > > > > > > > ]
> > > > > > > > > > > > > 13/11/2018 17:38, Burdick, Cliff:
> > > > > > > > > > > > > > From: Thomas Monjalon [mailto:thomas@monjalon
> > > > > > > > > > > > > > .net]
> > > > > > > > > > > > > > 13/11/2018 16:45, Burdick, Cliff:
> > > > > > > > > > > > > > > From: Burakov, Anatoly
> > > 
> > > [mailto:anatoly.burakov@intel.
> > > > > > > > > > > > > > > com]
> > > > > > > > > > > > > > > > On 13-Nov-18 9:21 AM, Thomas Monjalon
> > > > > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > > > > 13/11/2018 00:33, Burdick, Cliff:
> > > > > > > > > > > > > > > > > > This patch was submitted by Jean
> > > > > > > > > > > > > > > > > > Tourrilhes
> > > > > > > > > > > > > > > > > > over two years ago, but didn't
> > > > > > > > > > > > > > > > > > receive any
> > > 
> > > responses.
> > > > > > > > > > > > > > > > > > I hit the same issue recently when
> > > > > > > > > > > > > > > > > > trying to
> > > > > > > > > > > > > > > > > > use cgo
> > > > > > > > > > > > > > > > > > (Golang) as a primary process linked
> > > > > > > > > > > > > > > > > > to
> > > > > > > > > > > > > > > > > > libdpdk.a against a C++ application
> > > > > > > > > > > > > > > > > > linked
> > > > > > > > > > > > > > > > > > against the same library.> > >
> > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > The question is to know why you don't
> > > > > > > > > > > > > > > > > have the
> > > > > > > > > > > > > > > > > same constructors in primary and
> > > > > > > > > > > > > > > > > seconday?
> > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > I've hit similar things in the past. I
> > > > > > > > > > > > > > > > believe
> > > > > > > > > > > > > > > > it was caused by our build system
> > > > > > > > > > > > > > > > stripping out
> > > > > > > > > > > > > > > > unused libraries (such as
> > > > > > > > > > > > > > > > rte_hash) from the binary and thus not
> > > > > > > > > > > > > > > > calling
> > > > > > > > > > > > > > > > the constructor in the primary, but doing
> > > > > > > > > > > > > > > > so in
> > > > > > > > > > > > > > > > the secondary (or something to that
> > > > > > > > > > > > > > > > effect). In
> > > > > > > > > > > > > > > > any case, this is caused by linking
> > > > > > > > > > > > > > > > different
> > > > > > > > > > > > > > > > number of libraries to primary and
> > > > > > > > > > > > > > > > secondary,
> > > > > > > > > > > > > > > > and should probably be fixed in the build
> > > > > > > > > > > > > > > > system, not in the tailqs code (unless we
> > > > > > > > > > > > > > > > specifically support having different
> > > > > > > > > > > > > > > > linked
> > > > > > > > > > > > > > > > libraries to primary and secondary?).> >
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > Right, I think the original author of the
> > > > > > > > > > > > > > > patch
> > > > > > > > > > > > > > > stated the reasons in the link I provided.
> > > > > > > > > > > > > > > The
> > > > > > > > > > > > > > > build system seems like the most
> > > > > > > > > > > > > > > appropriate place
> > > > > > > > > > > > > > > to fix it, but the patch got me going
> > > > > > > > > > > > > > > quickly. I
> > > > > > > > > > > > > > > think the question is whether you want DPDK
> > > > > > > > > > > > > > > to
> > > > > > > > > > > > > > > support these other ways of linking.
> > > > > > > > > > > > > > > I'm
> > > > > > > > > > > > > > > certainly not the first to use cgo, since
> > > > > > > > > > > > > > > there's
> > > > > > > > > > > > > > > a virtual switch project doing the same:
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > https://urldefense.proofpoint.com/v2/url?u=
> > > > > > > > > > > > > > > https-3
> > > > > > > > > > > > > > > A__
> > > > > > > > > > > > > > > gith
> > > > > > > > > > > > > > > ub.co
> > > > > > > > > > > > > > > m_lago
> > > > > > > > > > > > > > > pu
> > > > > > > > > > > > > > > s_vsw&d=DwICAg&c=jcv3orpCsv7C4ly8-
> > > > > > > > > > > > > > > ubDoUfrxF5xIGWmptxGWP5vi5w&r =m1RLQ OG
> > > > > > > > > > > > > > > Okz9MauvVLZmiGtyWc5mA7DejbPFNE1IDj-
> > > > > > > > > > > > > > > 4&m=hQqVCNwW7eoEzB_hLFK97i8 idS8FI qX
> > > > > > > > > > > > > > > oPeclwsIZq7Y&s=BMoBlwkqljwWIBY3SE3pPMCfVnOU
> > > > > > > > > > > > > > > lDuZLrn
> > > > > > > > > > > > > > > o4-
> > > > > > > > > > > > > > > SojKM&e=
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > They don't use primary/secondary processes,
> > > > > > > > > > > > > > > though, so the issue is  never hit. I'm in
> > > > > > > > > > > > > > > a
> > > > > > > > > > > > > > > situation where using cgo seemed like the
> > > > > > > > > > > > > > > easiest
> > > > > > > > > > > > > > > path to accomplish what I'm doing since I
> > > > > > > > > > > > > > > needed
> > > > > > > > > > > > > > > specialized  libraries for it that were not
> > > > > > > > > > > > > > > available in C/C++. At some point I  bet
> > > > > > > > > > > > > > > someone
> > > > > > > > > > > > > > > would use Cython to start linking against
> > > > > > > > > > > > > > > DPDK as
> > > > > > > > > > > > > > > well,  and we'd likely run into the same
> > > > > > > > > > > > > > > issue.> >
> > > > > > > > > > > > > > > > > For sure, we want to support using DPDK
> > > > > > > > > > > > > > > > > with
> > > 
> > > cgo or cython.
> > > > > > > > > > > > > > > But it is not clear what is the relation
> > > > > > > > > > > > > > > with not
> > > > > > > > > > > > > > > having the same compilation for primary and
> > > 
> > > secondary.
> > > > > > > > > > > > > > > Please
> > > > > > > > > > > > > > > could you elaborate?> > >
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > Hi Thomas, I think Jean explained it well
> > > > > > > > > > > > > > here:
> > > > > > > > > > > > > > https://urldefense.proofpoint.com/v2/url?u=ht
> > > > > > > > > > > > > > tps-3A_
> > > > > > > > > > > > > > _de
> > > > > > > > > > > > > > v.dp
> > > > > > > > > > > > > > dk.narkive.
> > > > > > > > > > > > > > com_ZM3a7QD1_dpdk-2Ddev-2Dbug-2Dstatic-
> > > > > > > > > > > > > > 2Dconstructor
> > > > > > > > > > > > > > s-
> > > > > > > > > > > > > > 2Dconsider
> > > > > > > > > > > > > > ed-2De
> > > > > > > > > > > > > > vil&d=DwICAg&c=jcv3orpCsv7C4ly8-
> > > > > > > > > > > > > > ubDoUfrxF5xIGWmptxGWP5vi5w&r=m1R LQOGOk
> > > > > > > > > > > > > > z9MauvVLZmiGtyWc5mA7DejbPFNE1IDj-
> > > > > > > > > > > > > > 4&m=C69wDgrjDX8_oXp1M_3bnmWOOZd GqwBBG
> > > > > > > > > > > > > > 9vzkyGDWGQ&s=YYn2N7WrzJpH1ptNrLZad0nPAQdrUyqB
> > > > > > > > > > > > > > ckk2uFu
> > > > > > > > > > > > > > WYP
> > > > > > > > > > > > > > Q&e=
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > "The build system of the application does not
> > > > > > > > > > > > > > have
> > > > > > > > > > > > > > all the subtelties of the DPDK build system,
> > > > > > > > > > > > > > and
> > > > > > > > > > > > > > ends up including
> > > > > > > > > > > > > > *all*
> > > > > > > > > > > > > > the constructors, wether they are used or not
> > > > > > > > > > > > > > in the
> > > > > > > > > > > > > > code.
> > > > > > > > > > > > > > Moreover, they are included in a different
> > > > > > > > > > > > > > order.
> > > > > > > > > > > > > > Actually,
> > > > > > > > > > > > > > by default the builds include no constructors
> > > > > > > > > > > > > > at all
> > > > > > > > > > > > > > (which is a big fail), so the library needs
> > > > > > > > > > > > > > to be
> > > > > > > > > > > > > > included with --whole-archive (see Snort DPDK
> > > > > > > > > > > > > > instructions)."
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > I will get to the bottom of my exact case to
> > > > > > > > > > > > > > understand what's happening, but my primary
> > > > > > > > > > > > > > application is a cgo application that I'm
> > > > > > > > > > > > > > linking to
> > > > > > > > > > > > > > by using almost exactly the same flags that
> > > > > > > > > > > > > > are used
> > > > > > > > > > > > > > in the DPDK build system to build examples.
> > > > > > > > > > > > > > The DPDK
> > > > > > > > > > > > > > libraries I'm linking against is a single
> > > > > > > > > > > > > > location
> > > > > > > > > > > > > > for both primary and secondary; in other
> > > > > > > > > > > > > > words, I
> > > 
> > > don't build DPDK twice.
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > OK I understand, thanks.
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > You had alluded to a pkg-config for DPDK in
> > > > > > > > > > > > > > the 2015
> > > > > > > > > > > > > > thread, which cgo can use, but I don't know
> > > > > > > > > > > > > > if that
> > > > > > > > > > > > > > ever was implemented. Cgo can use pkg-config
> > > > > > > > > > > > > > if it's
> > > > > > > > > > > > > > available, otherwise the only tools are
> > > > > > > > > > > > > > specifying
> > > > > > > > > > > > > > LDFLAGS and CFLAGS into their build system.
> > > > > > > > > > > > > 
> > > > > > > > > > > > > Yes, the right answer is still pkg-config :)
> > > > > > > > > > > > > The good
> > > > > > > > > > > > > news is that it is now implemented thanks to
> > > > > > > > > > > > > the meson
> > > > > > > > > > > > > build
> > > > > > > > > > > > > system:
> > > > > > > > > > > > > 
> > > > > > > > > > > > > https://urldefense.proofpoint.com/v2/url?u=http
> > > > > > > > > > > > > -3A__gi
> > > > > > > > > > > > > t.d
> > > > > > > > > > > > > pdk.
> > > > > > > > > > > > > org_dp
> > > > > > > > > > > > > dk_tree_doc_build-2Dsdk-2Dmeson.txt-
> > > > > > > > > > > > > 23n182&d=DwICAg&c=jcv3orpCsv7C4
> > > > > > > > > > > > > ly8-
> > > > > > > > > > > > > ubDoUfrxF5xIGWmptxGWP5vi5w&r=m1RLQOGOkz9MauvVLZ
> > > > > > > > > > > > > miGtyWc
> > > > > > > > > > > > > 5mA
> > > > > > > > > > > > > 7Dej
> > > > > > > > > > > > > bP
> > > > > > > > > > > > > FNE1IDj-
> > > > > > > > > > > > > > 4&m=C69wDgrjDX8_oXp1M_3bnmWOOZdGqwBBG9vzkyGDW
> > > > > > > > > > > > > > GQ&s=oC
> > > > > > > > > > > > > > 86K
> > > > > > > > > > > > > > D_R
> > > > > > > > > > > > > 
> > > > > > > > > > > > > J1T6rfzi3x5zFT1Ri13ELpKmsyFqpgDbgFg&e=
> > > > > > > > > > > > 
> > > > > > > > > > > > Hi Thomas, are there instructions on how to use
> > > > > > > > > > > > pkg-config to build the mlx4/5 PMD? I noticed a
> > > > > > > > > > > > patch
> > > > > > > > > > > > was submitted in September to add support for it,
> > > > > > > > > > > > but
> > > > > > > > > > > > that link you provided on using meson doesn't say
> > > > > > > > > > > > how to
> > > > > > > > > > > > build specific drivers. It appears to be disabled
> > > > > > > > > > > > by
> > > 
> > > default.
> > > > > > > > > > > > If the dependency is found, meson will enable the
> > > > > > > > > > > > PMD
> > > > > > > > > > > > when building DPDK.
> > > > > > > > > > > 
> > > > > > > > > > > Do you know where exactly that is? I've been using
> > > > > > > > > > > mlx5
> > > > > > > > > > > for a while on this system, and I can see that
> > > > > > > > > > > 18.11-rc2
> > > > > > > > > > > meson
> > > > > > > > > > > build+ninja built the pmd, but it's not on the --
> > > > > > > > > > > libs
> > > > > > > > > > > build+listing
> > > > > > > > > > > for
> > > > > > > > > > > pkg-config. Does it tell me what I was missing?
> > > > > > > > > > > 
> > > > > > > > > > 
> > > > > > > > > > For dynamic linking of applications, the drivers are
> > > > > > > > > > not
> > > > > > > > > > normally linked in. Instead, they should be loaded
> > > > > > > > > > from the
> > > > > > > > > > drivers directory as .so files
> > > > > > > > > > - normally by default in EAL as the driver .so's
> > > > > > > > > > should be
> > > > > > > > > > copied to the EAL_PMD_PATH where EAL finds them
> > > 
> > > automatically.
> > > > > > > > > > [This applies to both meson and make builds, though
> > > > > > > > > > only
> > > > > > > > > > meson generates the .pc file for pkg-config]
> > > > > > > > > > 
> > > > > > > > > > If you are doing a static build, then you need to
> > > > > > > > > > explicitly
> > > > > > > > > > link in the drivers. You can get a list from pkg-
> > > > > > > > > > config
> > > > > > > > > > using the "
> > > > > > > > > > --static" flag in this case. A good example of how to
> > > > > > > > > > use
> > > > > > > > > > pkg- config in this way can be found in the Makefiles
> > > > > > > > > > for
> > > > > > > > > > most examples, e.g. examples/helloworld/Makefile,
> > > > > > > > > > reproduced
> > > 
> > > below.
> > > > > > > > > > 
> > > > > > > > > > Regards,
> > > > > > > > > > /Bruce
> > > > > > > > > > 
> > > > > > > > > > all: shared
> > > > > > > > > > .PHONY: shared static
> > > > > > > > > > shared: build/$(APP)-shared
> > > > > > > > > >         ln -sf $(APP)-shared build/$(APP)
> > > > > > > > > > static: build/$(APP)-static
> > > > > > > > > >         ln -sf $(APP)-static build/$(APP)
> > > > > > > > > > 
> > > > > > > > > > PC_FILE := $(shell pkg-config --path libdpdk) CFLAGS
> > > > > > > > > > += -O3
> > > > > > > > > > $(shell pkg-config --cflags libdpdk) LDFLAGS_SHARED =
> > > > > > > > > > $(shell
> > > > > > > > > > pkg- config -- libs libdpdk) LDFLAGS_STATIC = -Wl,-
> > > > > > > > > > Bstatic
> > > > > > > > > > $(shell pkg-config
> > > > > > > > > > --
> > > > > > > > > > static --libs libdpdk)
> > > > > > > > > > 
> > > > > > > > > > build/$(APP)-shared: $(SRCS-y) Makefile $(PC_FILE) |
> > > > > > > > > > build
> > > > > > > > > >         $(CC) $(CFLAGS) $(SRCS-y) -o $@ $(LDFLAGS)
> > > > > > > > > > $(LDFLAGS_SHARED)
> > > > > > > > > > 
> > > > > > > > > > build/$(APP)-static: $(SRCS-y) Makefile $(PC_FILE) |
> > > > > > > > > > build
> > > > > > > > > >         $(CC) $(CFLAGS) $(SRCS-y) -o $@ $(LDFLAGS)
> > > > > > > > > > $(LDFLAGS_STATIC)
> > > > > > > > > > 
> > > > > > > > > > build:
> > > > > > > > > >         @mkdir -p $@
> > > > > > > > > 
> > > > > > > > > Thanks Bruce. I tried getting this to compile using
> > > > > > > > > cgo, and
> > > > > > > > > it's causing more pain than it's worth. I used the --
> > > > > > > > > static
> > > > > > > > > --libs options, and there were still numerous linker
> > > > > > > > > errors,
> > > > > > > > > some specific to mlx, and some not. Specifically
> > > > > > > > > libmlx5 and
> > > > > > > > > libmnl are both needed, but they're not part of the
> > > > > > > > > linker
> > > > > > > > > line from pkg-config. At this point I'll just break the
> > > > > > > > > Go
> > > > > > > > > application up into a separate C application that
> > > > > > > > > handles all
> > > > > > > > > the DPDK parts, and send messages between them.
> > > > > > > > 
> > > > > > > > Hi,
> > > > > > > > 
> > > > > > > > As far as I can see, both mnl and mlx5 (and all the other
> > > > > > > > reverse
> > > > > > > > dependencies) are listed correctly in the libdpdk.pc
> > > > > > > > Libs.private entry, and pkg-config --libs --static
> > > > > > > > libdpdk.pc
> > > > > > > > does print them as intended. This is with 18.11-rc3.
> > > > > > > > Are you sure everything is correct (pkg-config path is
> > > > > > > > right, --
> > > > > > > > static is used, etc)?
> > > > > > > > 
> > > > > > > > --
> > > > > > > > Kind regards,
> > > > > > > > Luca Boccassi
> > > > > > > 
> > > > > > > Hi Luca, here is what pkg-config gives:
> > > > > > > 
> > > > > > > PKG_CONFIG_PATH=meson-private/ pkg-config --libs --static
> > > > > > > libdpdk
> > > > > > > -L/usr/local/lib/x86_64-linux-gnu -lrte_eventdev
> > > > > > > -lrte_power
> > > > > > > -lrte_ip_frag -lrte_hash -lrte_pdump -lrte_eal
> > > > > > > -lrte_pipeline
> > > > > > > -lrte_table -lrte_bbdev -lrte_bpf -lrte_vhost -lrte_metrics
> > > > > > > -lrte_jobstats -lrte_net -lrte_reorder -lrte_ring
> > > > > > > -lrte_mempool
> > > > > > > -lrte_security -lrte_compressdev -lrte_rawdev -lrte_mbuf
> > > > > > > -lrte_kvargs -lrte_port -lrte_pci -lrte_ethdev -lrte_gro
> > > > > > > -lrte_gso
> > > > > > > -lrte_cryptodev -lrte_sched -lrte_latencystats -lrte_efd
> > > > > > > -lrte_distributor -lrte_meter -lrte_acl -lrte_member
> > > > > > > -lrte_cmdline
> > > > > > > -lrte_lpm -lrte_kni -lrte_cfgfile -lrte_bitratestats
> > > > > > > -lrte_timer
> > > > > > > -lrte_flow_classify -lrte_mempool_bucket
> > > > > > > -lrte_pmd_null_crypto
> > > > > > > -lrte_pmd_failsafe -lrte_bus_ifpga -lrte_pmd_atlantic
> > > > > > > -lrte_pmd_mlx4 -lrte_pmd_vmxnet3 -lrte_pmd_avp
> > > > > > > -lrte_common_dpaax
> > > > > > > -lrte_pmd_ena -lcrypto -lrte_bus_fslmc -ldl -lrte_pmd_avf
> > > > > > > -lrte_pmd_crypto_scheduler -lrte_pmd_netvsc -lrte_pmd_vhost
> > > > > > > -lrte_bus_dpaa -lrte_mempool_dpaa2 -lrte_common_octeontx
> > > > > > > -lrte_pmd_liquidio -lrte_pmd_ifc -Wl,-Bdynamic -lnuma
> > > > > > > -lrte_pmd_enic -lrte_common_cpt -pthread
> > > > > > > -lrte_pmd_octeontx_crypto
> > > > > > > -lrte_pmd_qat -lrte_bus_vmbus -lrte_pmd_null -lm
> > > > > > > -lrte_pmd_dpaa
> > > > > > > -lrte_bus_vdev -lrte_pmd_dpaa2 -lrte_pmd_skeleton_event
> > > > > > > -lrte_pmd_af_packet -lrte_pmd_octeontx -lrte_pmd_thunderx
> > > > > > > -lrte_pmd_ring -lrte_pmd_octeontx_event -lrte_pmd_sw_event
> > > > > > > -lrte_pmd_ark -lrte_mempool_octeontx -lrte_pmd_ixgbe
> > > > > > > -lrte_pmd_kni
> > > > > > > -lrte_mempool_ring -lrte_pmd_virtio_crypto
> > > > > > > -lrte_mempool_dpaa
> > > > > > > -lrte_pmd_dpaa2_cmdif -lrte_bus_pci -lrte_pmd_opdl_event
> > > > > > > -lrte_pmd_mlx5 -lrte_pmd_virtio -lrte_pmd_tap
> > > > > > > -lrte_pmd_caam_jr
> > > > > > > -lrte_pmd_dpaa2_sec -lrte_pmd_dpaa2_qdma -lrte_pmd_enetc
> > > > > > > -lrte_pmd_sfc -lrte_pmd_bnxt -lrte_pmd_dpaa2_event
> > > > > > > -lrte_pmd_cxgbe
> > > > > > > -Wl,--whole-archive -Wl,--no- as-needed -lrte_pmd_e1000
> > > > > > > -lrte_pmd_softnic -lrte_pmd_bond -lrte_pmd_fm10k
> > > > > > > -lrte_pmd_i40e
> > > > > > > -lrte_pmd_nfp -lrte_pmd_qede -Wl,--no- whole-archive
> > > > > > > -lrte_pmd_axgbe -lrte_pmd_ccp -lrte_pmd_ifpga_rawdev
> > > > > > > -lrte_pmd_bbdev_null -lrte_pmd_openssl -lrte_pmd_dsw_event
> > > > > > > -lrte_pmd_dpaa_event -lrte_mempool_stack
> > > > > > > -lrte_pmd_vdev_netvsc
> > > > > > > -lrte_pmd_dpaa_sec -lrte_pmd_skeleton_rawdev
> > > > > > > -lrte_pmd_octeontx_compress
> > > > > > > 
> > > > > > > You'll notice there's no mlx5 or mnl in that list. I was
> > > > > > > using
> > > > > > > 18.11-
> > > > > > > rc2 since I cloned early yesterday. Perhaps meson
> > > > > > > determined not
> > > > > > > to put it in there for some reason?
> > > > > > 
> > > > > > Were mlx5/mnl found at meson configure time?
> > > > > > 
> > > > > > --
> > > > > > Kind regards,
> > > > > > Luca Boccassi
> > > > > 
> > > > > Hi Luca, yes, it was:
> > > > > 
> > > > > Library mnl found: YES
> > > > > Library mlx4 found: YES
> > > > > Library ibverbs found: YES
> > > > > Compiler for C supports argument -Wextra: YES Compiler for C
> > > > > supports
> > > > > argument -std=c11: YES Compiler for C supports argument
> > > > > -Wno-strict-prototypes: YES Compiler for C supports argument
> > > > > -D_BSD_SOURCE: YES Compiler for C supports argument
> > > > > -D_DEFAULT_SOURCE:
> > > > > YES Compiler for C supports argument -D_XOPEN_SOURCE=600: YES
> > > > > Checking
> > > > > whether type "struct mlx4_wqe_lso_seg" has member
> > > > > "mss_hdr_size": YES
> > > > > Configuring mlx4_autoconf.h using configuration Library mnl
> > > > > found: YES
> > > > > Library mlx5 found: YES Library ibverbs found: YES ...
> > > > > PKG_CONFIG_PATH=meson-private/ pkg-config --libs --static
> > > > > libdpdk
> > > > > -L/usr/local/lib/x86_64-linux-gnu -lrte_eventdev -lrte_power
> > > > > -lrte_ip_frag -lrte_hash -lrte_pdump -lrte_eal -lrte_pipeline
> > > > > -lrte_table -lrte_bbdev -lrte_bpf -lrte_vhost -lrte_metrics
> > > > > -lrte_jobstats -lrte_net -lrte_reorder -lrte_ring -lrte_mempool
> > > > > -lrte_security -lrte_compressdev -lrte_rawdev -lrte_mbuf
> > > > > -lrte_kvargs
> > > > > -lrte_port -lrte_pci -lrte_ethdev -lrte_gro -lrte_gso
> > > > > -lrte_cryptodev
> > > > > -lrte_sched -lrte_latencystats -lrte_efd -lrte_distributor
> > > > > -lrte_meter
> > > > > -lrte_acl -lrte_member -lrte_cmdline -lrte_lpm -lrte_kni
> > > > > -lrte_cfgfile
> > > > > -lrte_bitratestats -lrte_timer -lrte_flow_classify
> > > > > -lrte_pmd_ccp
> > > > > -lrte_mempool_bucket -lrte_pmd_failsafe -lrte_pmd_netvsc
> > > > > -lrte_pmd_null_crypto -lrte_bus_ifpga -lrte_pmd_atlantic
> > > > > -lrte_pmd_octeontx_event -lrte_pmd_avp -lrte_pmd_mlx4
> > > > > -lrte_common_dpaax -lrte_pmd_skeleton_rawdev -lrte_pmd_ena
> > > > > -lrte_pmd_opdl_event -lrte_bus_fslmc -lnuma -lrte_pmd_avf
> > > > > -lrte_pmd_crypto_scheduler -lrte_pmd_vhost -lrte_bus_dpaa
> > > > > -lrte_mempool_dpaa2 -lrte_common_octeontx -Wl,--no-as-needed
> > > > > -lcrypto
> > > > > -lrte_pmd_ifc -lrte_pmd_liquidio -lrte_pmd_enic
> > > > > -lrte_common_cpt
> > > > > -Wl,--no-whole-archive -lrte_bus_vmbus
> > > > > -lrte_pmd_octeontx_crypto
> > > > > -lrte_pmd_qat -lrte_pmd_ifpga_rawdev -lrte_pmd_dpaa
> > > > > -lrte_bus_vdev
> > > > > -lrte_pmd_bbdev_null -lrte_pmd_dpaa2 -lrte_pmd_skeleton_event
> > > > > -lrte_pmd_ring -lrte_pmd_af_packet -lrte_pmd_thunderx
> > > > > -lrte_pmd_dpaa_event -lrte_pmd_octeontx_compress
> > > > > -lrte_pmd_dpaa_sec
> > > > > -lrte_pmd_sw_event -Wl,--whole-archive -lrte_pmd_ark
> > > > > -lrte_mempool_octeontx -lrte_pmd_ixgbe -lrte_mempool_ring
> > > > > -lrte_pmd_kni -lrte_pmd_vmxnet3 -lrte_mempool_dpaa
> > > > > -lrte_bus_pci
> > > > > -lrte_pmd_dpaa2_cmdif -lrte_pmd_mlx5 -lrte_pmd_tap
> > > > > -lrte_pmd_caam_jr
> > > > > -lrte_pmd_dpaa2_sec -lm -lrte_pmd_dpaa2_qdma -lrte_pmd_enetc
> > > > > -lrte_pmd_virtio -lrte_pmd_bnxt -lrte_pmd_dpaa2_event
> > > > > -lrte_pmd_sfc
> > > > > -lrte_pmd_cxgbe -pthread -lrte_pmd_e1000 -lrte_pmd_softnic -ldl
> > > > > -lrte_pmd_null -lrte_pmd_bond -lrte_pmd_fm10k -lrte_pmd_i40e
> > > > > -lrte_pmd_nfp -lrte_pmd_qede -lrte_pmd_axgbe -Wl,-Bdynamic
> > > > > -lrte_pmd_openssl -lrte_pmd_octeontx -lrte_pmd_dsw_event
> > > > > -lrte_mempool_stack -lrte_pmd_virtio_crypto
> > > > > -lrte_pmd_vdev_netvsc
> > > > 
> > > > Is this with latest DPDK from git? because I see the exact same
> > > > as Luca:
> > > > 
> > > > $ PKG_CONFIG_PATH=build/meson-private/ pkg-config --libs --static
> > > 
> > > libdpdk | grep mlx
> > > > -L/usr/local/lib64 -lrte_telemetry -lrte_bpf -lrte_flow_classify
> > > > -
> > > 
> > > lrte_pipeline -lrte_table -lrte_port -lrte_vhost -lrte_security -
> > > lrte_sched -lrte_reorder -lrte_rawdev -lrte_pdump -lrte_power
> > > -lrte_meter
> > > -lrte_member -lrte_lpm -lrte_latencystats -lrte_kni -lrte_jobstats
> > > -
> > > lrte_ip_frag -lrte_gso -lrte_gro -lrte_eventdev -lrte_efd -
> > > lrte_distributor -lrte_cryptodev -lrte_compressdev -lrte_cfgfile -
> > > lrte_bitratestats -lrte_bbdev -lrte_acl -lrte_timer -lrte_hash -
> > > lrte_metrics -lrte_pci -lrte_ethdev -lrte_net -lrte_mbuf
> > > -lrte_mempool -
> > > lrte_ring -lrte_eal -lrte_kvargs -lrte_cmdline -L/usr/local/lib64 -
> > > lrte_kvargs -lrte_eal -lrte_ring -lrte_mempool -lrte_mbuf -lrte_pci
> > > -
> > > lrte_cryptodev -lrte_net -lrte_cmdline -lrte_ethdev -lrte_hash
> > > -lrte_timer
> > > -lrte_common_dpaax -lrte_eventdev -lrte_rawdev -lrte_bus_dpaa -
> > > lrte_bus_fslmc -lrte_bus_pci -lrte_common_octeontx -lrte_bus_vdev -
> > > lrte_meter -lrte_sched -lrte_ip_frag -lz -lrte_mempool_dpaa -
> > > lrte_mempool_dpaa2 -lrte_vhost -lrte_security -lrte_kni -lmnl
> > > -lmlx4 -
> > > libverbs -lmnl -lmlx5 -libverbs -lrte_bus_vmbus
> > > -lrte_mempool_octeontx -
> > > lpcap -lrte_port -lrte_lpm -lrte_acl -lrte_table -lrte_pipeline
> > > -lsze2 -
> > > lrte_gso -lIPSec_MB -lIPSec_MB -lrte_common_cpt -lrte_reorder -
> > > lrte_compressdev -lrte_pmd_dpaa -lrte_pmd_dpaa2 -lrte_pmd_dpaa2_sec
> > > -
> > > lrte_pmd_octeontx -lrte_bbdev -lrte_bus_ifpga -Wl,--whole-archive -
> > > lrte_mempool_bucket -lrte_mempool_ring -lrte_mempool_stack -
> > > lrte_pmd_af_packet -lrte_pmd_ark -lrte_pmd_atlantic -lrte_pmd_avf -
> > > lrte_pmd_avp -lrte_pmd_axgbe -lrte_pmd_bond -lrte_pmd_bnx2x
> > > -lrte_pmd_bnxt
> > > -lrte_pmd_cxgbe -lrte_pmd_e1000 -lrte_pmd_ena -lrte_pmd_enetc -
> > > lrte_pmd_enic -lrte_pmd_failsafe -lrte_pmd_fm10k -lrte_pmd_i40e -
> > > lrte_pmd_ifc -lrte_pmd_ixgbe -lrte_pmd_kmod -lrte_pmd_kni -
> > > lrte_pmd_liquidio -lrte_pmd_mlx4 -lrte_pmd_mlx5 -lrte_pmd_netvsc -
> > > lrte_pmd_nfp -lrte_pmd_null -lrte_pmd_pcap -lrte_pmd_qede
> > > -lrte_pmd_ring -
> > > lrte_pmd_sfc -lrte_pmd_softnic -lrte_pmd_szedata2 -lrte_pmd_tap -
> > > lrte_pmd_thunderx -lrte_pmd_vdev_netvsc -lrte_pmd_vhost
> > > -lrte_pmd_virtio -
> > > lrte_pmd_vmxnet3 -lrte_pmd_aesni_gcm -lrte_pmd_aesni_mb
> > > -lrte_pmd_caam_jr
> > > -lrte_pmd_ccp -lrte_pmd_dpaa_sec -lrte_pmd_null_crypto -
> > > lrte_pmd_octeontx_crypto -lrte_pmd_openssl
> > > -lrte_pmd_crypto_scheduler -
> > > lrte_pmd_virtio_crypto -lrte_pmd_octeontx_compress -lrte_pmd_qat -
> > > lrte_pmd_zlib -lrte_pmd_dpaa_event -lrte_pmd_dpaa2_event -
> > > lrte_pmd_octeontx_event -lrte_pmd_opdl_event
> > > -lrte_pmd_skeleton_event -
> > > lrte_pmd_sw_event -lrte_pmd_dsw_event -lrte_pmd_bbdev_null -
> > > lrte_pmd_skeleton_rawdev -lrte_pmd_dpaa2_cmdif -lrte_pmd_dpaa2_qdma
> > > -
> > > lrte_pmd_ifpga_rawdev -lrte_pmd_ioat_copy -Wl,--no-whole-archive
> > > -Wl,-
> > > Bdynamic -Wl,--no-as-needed -pthread -lm -ldl -lnuma -lbsd -lpcap
> > > -lcrypto
> > > -lcrypto -lz -lcrypto -ldl -pthread -lz
> > > 
> > > Hi Bruce, I tried with rc3 and a new clone from right now, and get
> > > the
> > > same results:
> > > 
> > > $ meson build
> > > The Meson build system
> > > Version: 0.45.1
> > > Source dir: /home/cburdick/dpdk
> > > Build dir: /home/cburdick/dpdk/build
> > > Build type: native build
> > > Project name: DPDK
> > > Native C compiler: cc (gcc 7.3.0 "cc (Ubuntu 7.3.0-27ubuntu1~18.04)
> > > 7.3.0")
> > > Build machine cpu family: x86_64
> > > Build machine cpu: x86_64
> > > Library numa found: YES
> > > Has header "numaif.h": YES
> > > Library bsd found: NO
> > > Checking for size of "void *": 8
> > > Compiler for C supports argument -Wsign-compare: YES
> > > Compiler for C supports argument -Wcast-qual: YES
> > > Compiler for C supports argument -Wno-address-of-packed-member: YES
> > > Fetching value of define "__SSE4_2__": 1
> > > Fetching value of define "__AES__": 1
> > > Fetching value of define "__PCLMUL__": 1
> > > Fetching value of define "__AVX__": 1
> > > Fetching value of define "__AVX2__": 1
> > > Fetching value of define "__AVX512F__":
> > > Compiler for C supports argument -Wno-format-truncation: YES
> > > Checking for size of "void *": 8
> > > Has header "linux/userfaultfd.h": YES
> > > Checking for size of "void *": 8
> > > Library elf found: NO
> > > Library jansson found: NO
> > > Program gen-pmdinfo-cfile.sh found: YES
> > > (/home/cburdick/dpdk/buildtools/gen-pmdinfo-cfile.sh)
> > > Compiler for C supports argument -Wno-format-truncation: YES
> > > Library libmusdk found: NO
> > > Compiler for C supports argument -Wno-cast-qual: YES
> > > Compiler for C supports argument -Wno-pointer-to-int-cast: YES
> > > Library z found: NO
> > > Compiler for C supports argument -Wno-uninitialized: YES
> > > Compiler for C supports argument -Wno-unused-parameter: YES
> > > Compiler for C supports argument -Wno-unused-variable: YES
> > > Compiler for C supports argument -Wno-misleading-indentation: YES
> > > Compiler for C supports argument -Wno-implicit-fallthrough: YES
> > > Checking for size of "void *": 8
> > > Compiler for C supports argument -Wno-unused-parameter: YES
> > > Compiler for C supports argument -Wno-unused-value: YES
> > > Compiler for C supports argument -Wno-strict-aliasing: YES
> > > Compiler for C supports argument -Wno-format-extra-args: YES
> > > Compiler for C supports argument -Wno-unused-variable: YES
> > > Compiler for C supports argument -Wno-missing-field-initializers:
> > > YES
> > > Compiler for C supports argument -Wno-sign-compare: YES
> > > Compiler for C supports argument -Wno-unused-value: YES
> > > Compiler for C supports argument -Wno-format: YES
> > > Compiler for C supports argument -Wno-error=format-security: YES
> > > Compiler for C supports argument -Wno-strict-aliasing: YES
> > > Compiler for C supports argument -Wno-unused-but-set-variable: YES
> > > Compiler for C supports argument -Wno-unused-value: YES
> > > Compiler for C supports argument -Wno-unused-but-set-variable: YES
> > > Library mnl found: YES
> > > Library mlx4 found: YES
> > > Library ibverbs found: YES
> > > Compiler for C supports argument -Wextra: YES
> > > Compiler for C supports argument -std=c11: YES
> > > Compiler for C supports argument -Wno-strict-prototypes: YES
> > > Compiler for C supports argument -D_BSD_SOURCE: YES
> > > Compiler for C supports argument -D_DEFAULT_SOURCE: YES
> > > Compiler for C supports argument -D_XOPEN_SOURCE=600: YES
> > > Checking whether type "struct mlx4_wqe_lso_seg" has member
> > > "mss_hdr_size":
> > > YES
> > > Configuring mlx4_autoconf.h using configuration
> > > Library mnl found: YES
> > > Library mlx5 found: YES
> > > Library ibverbs found: YES
> > > Compiler for C supports argument -Wextra: YES
> > > Compiler for C supports argument -std=c11: YES
> > > Compiler for C supports argument -Wno-strict-prototypes: YES
> > > Compiler for C supports argument -D_BSD_SOURCE: YES
> > > Compiler for C supports argument -D_DEFAULT_SOURCE: YES
> > > Compiler for C supports argument -D_XOPEN_SOURCE=600: YES
> > > Header <infiniband/mlx5dv.h> has symbol
> > > "MLX5DV_CQE_RES_FORMAT_CSUM_STRIDX": YES
> > > Header <infiniband/mlx5dv.h> has symbol
> > > "MLX5DV_CONTEXT_MASK_TUNNEL_OFFLOADS": YES
> > > Header <infiniband/mlx5dv.h> has symbol
> > > "MLX5DV_CONTEXT_FLAGS_MPW_ALLOWED": YES
> > > Header <infiniband/mlx5dv.h> has symbol
> > > "MLX5DV_CONTEXT_FLAGS_CQE_128B_COMP": YES
> > > Header <infiniband/mlx5dv.h> has symbol
> > > "MLX5DV_CQ_INIT_ATTR_FLAGS_CQE_PAD": YES
> > > Header <infiniband/mlx5dv.h> has symbol
> > > "mlx5dv_create_flow_action_packet_reformat": NO
> > > Header <infiniband/verbs.h> has symbol "IBV_FLOW_SPEC_MPLS": YES
> > > Header <infiniband/verbs.h> has symbol
> > > "IBV_WQ_FLAG_RX_END_PADDING": NO
> > > Header <linux/ethtool.h> has symbol "SUPPORTED_40000baseKR4_Full":
> > > YES
> > > Header <linux/ethtool.h> has symbol "SUPPORTED_40000baseCR4_Full":
> > > YES
> > > Header <linux/ethtool.h> has symbol "SUPPORTED_40000baseSR4_Full":
> > > YES
> > > Header <linux/ethtool.h> has symbol "SUPPORTED_40000baseLR4_Full":
> > > YES
> > > Header <linux/ethtool.h> has symbol "SUPPORTED_56000baseKR4_Full":
> > > YES
> > > Header <linux/ethtool.h> has symbol "SUPPORTED_56000baseCR4_Full":
> > > YES
> > > Header <linux/ethtool.h> has symbol "SUPPORTED_56000baseSR4_Full":
> > > YES
> > > Header <linux/ethtool.h> has symbol "SUPPORTED_56000baseLR4_Full":
> > > YES
> > > Header <linux/ethtool.h> has symbol
> > > "ETHTOOL_LINK_MODE_25000baseCR_Full_BIT": YES
> > > Header <linux/ethtool.h> has symbol
> > > "ETHTOOL_LINK_MODE_50000baseCR2_Full_BIT": YES
> > > Header <linux/ethtool.h> has symbol
> > > "ETHTOOL_LINK_MODE_100000baseKR4_Full_BIT": YES
> > > Header <linux/if_link.h> has symbol "IFLA_PHYS_SWITCH_ID": YES
> > > Header <linux/if_link.h> has symbol "IFLA_PHYS_PORT_NAME": YES
> > > Header <linux/if_link.h> has symbol "IFLA_VXLAN_COLLECT_METADATA":
> > > YES
> > > Header <linux/rtnetlink.h> has symbol "TCA_CHAIN": YES
> > > Header <linux/pkt_cls.h> has symbol "TCA_FLOWER_ACT": YES
> > > Header <linux/pkt_cls.h> has symbol "TCA_FLOWER_FLAGS": YES
> > > Header <linux/pkt_cls.h> has symbol "TCA_FLOWER_KEY_ETH_TYPE": YES
> > > Header <linux/pkt_cls.h> has symbol "TCA_FLOWER_KEY_ETH_DST": YES
> > > Header <linux/pkt_cls.h> has symbol "TCA_FLOWER_KEY_ETH_DST_MASK":
> > > YES
> > > Header <linux/pkt_cls.h> has symbol "TCA_FLOWER_KEY_ETH_SRC": YES
> > > Header <linux/pkt_cls.h> has symbol "TCA_FLOWER_KEY_ETH_SRC_MASK":
> > > YES
> > > Header <linux/pkt_cls.h> has symbol "TCA_FLOWER_KEY_IP_PROTO": YES
> > > Header <linux/pkt_cls.h> has symbol "TCA_FLOWER_KEY_IPV4_SRC": YES
> > > Header <linux/pkt_cls.h> has symbol "TCA_FLOWER_KEY_IPV4_SRC_MASK":
> > > YES
> > > Header <linux/pkt_cls.h> has symbol "TCA_FLOWER_KEY_IPV4_DST": YES
> > > Header <linux/pkt_cls.h> has symbol "TCA_FLOWER_KEY_IPV4_DST_MASK":
> > > YES
> > > Header <linux/pkt_cls.h> has symbol "TCA_FLOWER_KEY_IPV6_SRC": YES
> > > Header <linux/pkt_cls.h> has symbol "TCA_FLOWER_KEY_IPV6_SRC_MASK":
> > > YES
> > > Header <linux/pkt_cls.h> has symbol "TCA_FLOWER_KEY_IPV6_DST": YES
> > > Header <linux/pkt_cls.h> has symbol "TCA_FLOWER_KEY_IPV6_DST_MASK":
> > > YES
> > > Header <linux/pkt_cls.h> has symbol "TCA_FLOWER_KEY_TCP_SRC": YES
> > > Header <linux/pkt_cls.h> has symbol "TCA_FLOWER_KEY_TCP_SRC_MASK":
> > > YES
> > > Header <linux/pkt_cls.h> has symbol "TCA_FLOWER_KEY_TCP_DST": YES
> > > Header <linux/pkt_cls.h> has symbol "TCA_FLOWER_KEY_TCP_DST_MASK":
> > > YES
> > > Header <linux/pkt_cls.h> has symbol "TCA_FLOWER_KEY_UDP_SRC": YES
> > > Header <linux/pkt_cls.h> has symbol "TCA_FLOWER_KEY_UDP_SRC_MASK":
> > > YES
> > > Header <linux/pkt_cls.h> has symbol "TCA_FLOWER_KEY_UDP_DST": YES
> > > Header <linux/pkt_cls.h> has symbol "TCA_FLOWER_KEY_UDP_DST_MASK":
> > > YES
> > > Header <linux/pkt_cls.h> has symbol "TCA_FLOWER_KEY_VLAN_ID": YES
> > > Header <linux/pkt_cls.h> has symbol "TCA_FLOWER_KEY_VLAN_PRIO": YES
> > > Header <linux/pkt_cls.h> has symbol "TCA_FLOWER_KEY_VLAN_ETH_TYPE":
> > > YES
> > > Header <linux/pkt_cls.h> has symbol "TCA_FLOWER_KEY_TCP_FLAGS": YES
> > > Header <linux/pkt_cls.h> has symbol
> > > "TCA_FLOWER_KEY_TCP_FLAGS_MASK": YES
> > > Header <linux/pkt_cls.h> has symbol "TC_ACT_GOTO_CHAIN": YES
> > > Header <linux/tc_act/tc_vlan.h> has symbol
> > > "TCA_VLAN_PUSH_VLAN_PRIORITY":
> > > YES
> > > Header <linux/pkt_cls.h> has symbol "TCA_FLOWER_KEY_ENC_KEY_ID":
> > > YES
> > > Header <linux/pkt_cls.h> has symbol "TCA_FLOWER_KEY_ENC_IPV4_SRC":
> > > YES
> > > Header <linux/pkt_cls.h> has symbol
> > > "TCA_FLOWER_KEY_ENC_IPV4_SRC_MASK":
> > > YES
> > > Header <linux/pkt_cls.h> has symbol "TCA_FLOWER_KEY_ENC_IPV4_DST":
> > > YES
> > > Header <linux/pkt_cls.h> has symbol
> > > "TCA_FLOWER_KEY_ENC_IPV4_DST_MASK":
> > > YES
> > > Header <linux/pkt_cls.h> has symbol "TCA_FLOWER_KEY_ENC_IPV6_SRC":
> > > YES
> > > Header <linux/pkt_cls.h> has symbol
> > > "TCA_FLOWER_KEY_ENC_IPV6_SRC_MASK":
> > > YES
> > > Header <linux/pkt_cls.h> has symbol "TCA_FLOWER_KEY_ENC_IPV6_DST":
> > > YES
> > > Header <linux/pkt_cls.h> has symbol
> > > "TCA_FLOWER_KEY_ENC_IPV6_DST_MASK":
> > > YES
> > > Header <linux/pkt_cls.h> has symbol
> > > "TCA_FLOWER_KEY_ENC_UDP_SRC_PORT": YES
> > > Header <linux/pkt_cls.h> has symbol
> > > "TCA_FLOWER_KEY_ENC_UDP_SRC_PORT_MASK": YES
> > > Header <linux/pkt_cls.h> has symbol
> > > "TCA_FLOWER_KEY_ENC_UDP_DST_PORT": YES
> > > Header <linux/pkt_cls.h> has symbol
> > > "TCA_FLOWER_KEY_ENC_UDP_DST_PORT_MASK": YES
> > > Header <linux/tc_act/tc_tunnel_key.h> has symbol
> > > "TCA_ACT_TUNNEL_KEY": YES
> > > Header <linux/tc_act/tc_tunnel_key.h> has symbol
> > > "TCA_TUNNEL_KEY_ENC_DST_PORT": YES
> > > Header <linux/tc_act/tc_tunnel_key.h> has symbol
> > > "TCA_TUNNEL_KEY_NO_CSUM":
> > > YES
> > > Header <linux/tc_act/tc_pedit.h> has symbol
> > > "TCA_PEDIT_KEY_EX_HDR_TYPE_UDP": YES
> > > Header <rdma/rdma_netlink.h> has symbol "RDMA_NL_NLDEV": YES
> > > Header <rdma/rdma_netlink.h> has symbol "RDMA_NLDEV_CMD_GET": YES
> > > Header <rdma/rdma_netlink.h> has symbol "RDMA_NLDEV_CMD_PORT_GET":
> > > YES
> > > Header <rdma/rdma_netlink.h> has symbol
> > > "RDMA_NLDEV_ATTR_DEV_INDEX": YES
> > > Header <rdma/rdma_netlink.h> has symbol "RDMA_NLDEV_ATTR_DEV_NAME":
> > > YES
> > > Header <rdma/rdma_netlink.h> has symbol
> > > "RDMA_NLDEV_ATTR_PORT_INDEX": YES
> > > Header <rdma/rdma_netlink.h> has symbol
> > > "RDMA_NLDEV_ATTR_NDEV_INDEX": NO
> > > Checking whether type "struct mlx5dv_sw_parsing_caps" has member
> > > "sw_parsing_offloads": YES
> > > Checking whether type "struct ibv_counter_set_init_attr" has member
> > > "counter_set_id": YES
> > > Checking whether type "struct ibv_counters_init_attr" has member
> > > "comp_mask": NO
> > > Configuring mlx5_autoconf.h using configuration
> > > Library libmusdk found: NO
> > > Library libmusdk found: NO
> > > Library pcap found: NO
> > > Compiler for C supports argument -Wno-unused-parameter: YES
> > > Compiler for C supports argument -Wno-sign-compare: YES
> > > Compiler for C supports argument -Wno-missing-prototypes: YES
> > > Compiler for C supports argument -Wno-cast-qual: YES
> > > Compiler for C supports argument -Wno-unused-function: YES
> > > Compiler for C supports argument -Wno-unused-variable: YES
> > > Compiler for C supports argument -Wno-strict-aliasing: YES
> > > Compiler for C supports argument -Wno-missing-prototypes: YES
> > > Compiler for C supports argument -Wno-unused-value: YES
> > > Compiler for C supports argument -Wno-format-nonliteral: YES
> > > Compiler for C supports argument -Wno-shift-negative-value: YES
> > > Compiler for C supports argument -Wno-unused-but-set-variable: YES
> > > Compiler for C supports argument -Wno-missing-declarations: YES
> > > Compiler for C supports argument -Wno-maybe-uninitialized: YES
> > > Compiler for C supports argument -Wno-strict-prototypes: YES
> > > Compiler for C supports argument -Wno-shift-negative-value: YES
> > > Compiler for C supports argument -Wno-implicit-fallthrough: YES
> > > Compiler for C supports argument -Wno-format-extra-args: YES
> > > Compiler for C supports argument -Wno-visibility: YES
> > > Compiler for C supports argument -Wno-empty-body: YES
> > > Compiler for C supports argument -Wno-invalid-source-encoding: YES
> > > Compiler for C supports argument -Wno-sometimes-uninitialized: YES
> > > Compiler for C supports argument -Wno-pointer-bool-conversion: YES
> > > Checking for size of "void *": 8
> > > Compiler for C supports argument -Wno-strict-aliasing: YES
> > > Compiler for C supports argument -Wextra: YES
> > > Compiler for C supports argument -Wdisabled-optimization: YES
> > > Compiler for C supports argument -Waggregate-return: YES
> > > Compiler for C supports argument -Wnested-externs: YES
> > > Compiler for C supports argument -Wbad-function-cast: YES
> > > Compiler for C supports argument -Wno-sign-compare: YES
> > > Compiler for C supports argument -Wno-unused-parameter: YES
> > > Compiler for C supports argument -Wno-unused-variable: YES
> > > Compiler for C supports argument -Wno-empty-body: YES
> > > Compiler for C supports argument -Wno-unused-but-set-variable: YES
> > > Library sze2 found: NO
> > > Header <linux/pkt_cls.h> has symbol "TCA_FLOWER_UNSPEC": YES
> > > Header <linux/pkt_cls.h> has symbol "TCA_FLOWER_KEY_VLAN_PRIO": YES
> > > Header <linux/pkt_cls.h> has symbol "TCA_BPF_UNSPEC": YES
> > > Header <linux/pkt_cls.h> has symbol "TCA_BPF_FD": YES
> > > Header <linux/tc_act/tc_bpf.h> has symbol "TCA_ACT_BPF_UNSPEC": YES
> > > Header <linux/tc_act/tc_bpf.h> has symbol "TCA_ACT_BPF_FD": YES
> > > Configuring tap_autoconf.h using configuration
> > > Compiler for C supports argument -fno-prefetch-loop-arrays: YES
> > > Compiler for C supports argument -Wno-maybe-uninitialized: YES
> > > Compiler for C supports argument -Wall: YES
> > > Compiler for C supports argument -Wextra: YES
> > > Compiler for C supports argument -D_BSD_SOURCE: YES
> > > Compiler for C supports argument -D_DEFAULT_SOURCE: YES
> > > Compiler for C supports argument -D_XOPEN_SOURCE=600: YES
> > > Compiler for C supports argument -Wno-unused-parameter: YES
> > > Compiler for C supports argument -Wno-unused-value: YES
> > > Compiler for C supports argument -Wno-strict-aliasing: YES
> > > Compiler for C supports argument -Wno-format-extra-args: YES
> > > Library IPSec_MB found: NO
> > > Library IPSec_MB found: NO
> > > Found pkg-config: /usr/bin/pkg-config (0.29.1)
> > > Native dependency libcrypto found: YES 1.1.0g
> > > Library libsso_kasumi found: NO
> > > Library libmusdk found: NO
> > > Dependency libcrypto found: YES (cached)
> > > Dependency libcrypto found: YES (cached)
> > > Library libsso_zuc found: NO
> > > Dependency libisal found: NO
> > > Dependency zlib found: NO
> > > Compiler for C supports argument -Wno-sign-compare: YES
> > > Compiler for C supports argument -Wno-unused-value: YES
> > > Compiler for C supports argument -Wno-format: YES
> > > Compiler for C supports argument -Wno-error=format-security: YES
> > > Compiler for C supports argument -Wno-strict-aliasing: YES
> > > Compiler for C supports argument -Wno-unused-but-set-variable: YES
> > > Library execinfo found: NO
> > > Compiler for C supports argument -Wno-format-truncation: YES
> > > Dependency zlib found: NO
> > > Library execinfo found: NO
> > > Program doxygen found: NO
> > > Program sphinx-build found: NO
> > > kernel/linux/kni/meson.build:16: WARNING: Passed invalid keyword
> > > argument
> > > "console".
> > > WARNING: This will become a hard error in the future.
> > > WARNING: Unknown keyword arguments in target rte_kni: console
> > > Configuring rte_build_config.h using configuration
> > > Program buildtools/symlink-drivers-solibs.sh found: YES (/bin/sh
> > > /home/cburdick/dpdk/buildtools/symlink-drivers-solibs.sh)
> > > Message:
> > > =================
> > > Libraries Enabled
> > > =================
> > > 
> > > libs:
> > > \tcompat, cmdline, kvargs, eal, ring, mempool, mbuf, net,
> > > \tethdev, pci, metrics, hash, timer, acl, bbdev, bitratestats,
> > > \tcfgfile, compressdev, cryptodev, distributor, efd, eventdev, gro,
> > > gso,
> > > \tip_frag, jobstats, kni, latencystats, lpm, member, meter, power,
> > > \tpdump, rawdev, reorder, sched, security, vhost, port, table,
> > > \tpipeline, flow_classify, bpf,
> > > 
> > > Build targets in project: 411
> > > Found ninja-1.8.2 at /usr/bin/ninja
> > > [cburdick@dev01 ~/dpdk] (master)
> > > $ cd build
> > > [cburdick@dev01 ~/dpdk/build] (master)
> > > $ ninja
> > > [1428/1431] Generating igb_uio with a custom command.
> > > make: Entering directory '/usr/src/linux-headers-4.15.0-20-generic'
> > > Makefile:976: "Cannot use CONFIG_STACK_VALIDATION=y, please install
> > > libelf-dev, libelf-devel or elfutils-libelf-devel"
> > >   CC [M]  /home/cburdick/dpdk/build/kernel/linux/igb_uio/igb_uio.o
> > >   Building modules, stage 2.
> > >   MODPOST 1 modules
> > >  
> > > CC      /home/cburdick/dpdk/build/kernel/linux/igb_uio/igb_uio.mod.
> > > o
> > >   LD [M]  /home/cburdick/dpdk/build/kernel/linux/igb_uio/igb_uio.ko
> > > make: Leaving directory '/usr/src/linux-headers-4.15.0-20-generic'
> > > [1431/1431] Generating rte_kni with a custom command.
> > > make: Entering directory '/usr/src/linux-headers-4.15.0-20-generic'
> > > Makefile:976: "Cannot use CONFIG_STACK_VALIDATION=y, please install
> > > libelf-dev, libelf-devel or elfutils-libelf-devel"
> > >   CC [M]  /home/cburdick/dpdk/build/kernel/linux/kni/kni_net.o
> > >   CC [M]  /home/cburdick/dpdk/build/kernel/linux/kni/kni_misc.o
> > >   CC [M]  /home/cburdick/dpdk/build/kernel/linux/kni/kni_ethtool.o
> > >   CC [M]
> > > /home/cburdick/dpdk/build/kernel/linux/kni/ethtool/ixgbe/ixgbe_etht
> > > ool.o
> > >   CC [M]
> > > /home/cburdick/dpdk/build/kernel/linux/kni/ethtool/ixgbe/ixgbe_8259
> > > 9.o
> > >   CC [M]
> > > /home/cburdick/dpdk/build/kernel/linux/kni/ethtool/ixgbe/ixgbe_api.
> > > o
> > >   CC [M]
> > > /home/cburdick/dpdk/build/kernel/linux/kni/ethtool/ixgbe/ixgbe_x540
> > > .o
> > >   CC [M]
> > > /home/cburdick/dpdk/build/kernel/linux/kni/ethtool/ixgbe/ixgbe_comm
> > > on.o
> > >   CC [M]
> > > /home/cburdick/dpdk/build/kernel/linux/kni/ethtool/ixgbe/ixgbe_phy.
> > > o
> > >   CC [M]
> > > /home/cburdick/dpdk/build/kernel/linux/kni/ethtool/ixgbe/ixgbe_8259
> > > 8.o
> > >   CC [M]
> > > /home/cburdick/dpdk/build/kernel/linux/kni/ethtool/ixgbe/ixgbe_main
> > > .o
> > >   CC [M]
> > > /home/cburdick/dpdk/build/kernel/linux/kni/ethtool/ixgbe/kcompat.o
> > >   CC [M]
> > > /home/cburdick/dpdk/build/kernel/linux/kni/ethtool/igb/e1000_82575.
> > > o
> > >   CC [M]
> > > /home/cburdick/dpdk/build/kernel/linux/kni/ethtool/igb/e1000_i210.o
> > >   CC [M]
> > > /home/cburdick/dpdk/build/kernel/linux/kni/ethtool/igb/e1000_mbx.o
> > >   CC [M]
> > > /home/cburdick/dpdk/build/kernel/linux/kni/ethtool/igb/e1000_api.o
> > >   CC [M]
> > > /home/cburdick/dpdk/build/kernel/linux/kni/ethtool/igb/igb_main.o
> > >   CC [M]
> > > /home/cburdick/dpdk/build/kernel/linux/kni/ethtool/igb/igb_vmdq.o
> > >   CC [M]
> > > /home/cburdick/dpdk/build/kernel/linux/kni/ethtool/igb/e1000_manage
> > > .o
> > >   CC [M]
> > > /home/cburdick/dpdk/build/kernel/linux/kni/ethtool/igb/igb_ethtool.
> > > o
> > >   CC [M]
> > > /home/cburdick/dpdk/build/kernel/linux/kni/ethtool/igb/igb_param.o
> > >   CC [M]
> > > /home/cburdick/dpdk/build/kernel/linux/kni/ethtool/igb/e1000_mac.o
> > >   CC [M]
> > > /home/cburdick/dpdk/build/kernel/linux/kni/ethtool/igb/e1000_phy.o
> > >   CC [M]
> > > /home/cburdick/dpdk/build/kernel/linux/kni/ethtool/igb/e1000_nvm.o
> > >   LD [M]  /home/cburdick/dpdk/build/kernel/linux/kni/rte_kni.o
> > >   Building modules, stage 2.
> > >   MODPOST 1 modules
> > >   CC      /home/cburdick/dpdk/build/kernel/linux/kni/rte_kni.mod.o
> > >   LD [M]  /home/cburdick/dpdk/build/kernel/linux/kni/rte_kni.ko
> > > make: Leaving directory '/usr/src/linux-headers-4.15.0-20-generic'
> > > [cburdick@dev01 ~/dpdk/build] (master)
> > > $ PKG_CONFIG_PATH=meson-private/ pkg-config --libs --static
> > > libdpdk|grep
> > > mlx
> > > -L/usr/local/lib/x86_64-linux-gnu -lrte_flow_classify
> > > -lrte_eventdev -
> > > lrte_ip_frag -lrte_power -lrte_hash -lrte_pdump -lrte_pipeline
> > > -lrte_table
> > > -lrte_mbuf -lrte_bbdev -lrte_bpf -lrte_vhost -lrte_metrics
> > > -lrte_mempool -
> > > lrte_jobstats -lrte_reorder -lrte_net -lrte_security -lrte_eal
> > > -lrte_ring
> > > -lrte_ethdev -lrte_compressdev -lrte_rawdev -lrte_kvargs -lrte_pci
> > > -
> > > lrte_cfgfile -lrte_gro -lrte_gso -lrte_cryptodev -lrte_latencystats
> > > -
> > > lrte_sched -lrte_efd -lrte_distributor -lrte_acl -lrte_member -
> > > lrte_cmdline -lrte_lpm -lrte_meter -lrte_kni -lrte_bitratestats -
> > > lrte_timer -lrte_port -lrte_mempool_bucket -lrte_pmd_vdev_netvsc -
> > > lrte_pmd_ark -lrte_pmd_failsafe -lrte_pmd_netvsc
> > > -lrte_pmd_null_crypto -
> > > lrte_bus_ifpga -lrte_common_dpaax -lrte_pmd_ixgbe
> > > -lrte_mempool_ring -
> > > lrte_pmd_kni -lrte_pmd_vmxnet3 -lrte_pmd_mlx4 -lrte_pmd_virtio
> > > -Wl,--no-
> > > as-needed -lrte_mempool_dpaa -lrte_pmd_ena -lrte_bus_fslmc
> > > -lrte_pmd_avf -
> > > lrte_pmd_dpaa2_sec -lrte_common_octeontx -lrte_pmd_skeleton_rawdev
> > > -
> > > lrte_pmd_crypto_scheduler -lrte_pmd_dpaa2_qdma -lrte_pmd_vhost -ldl
> > > -
> > > lrte_bus_dpaa -lrte_pmd_fm10k -lrte_pmd_bnxt -lrte_pmd_qat
> > > -lrte_pmd_bond
> > > -lrte_pmd_axgbe -lrte_pmd_dpaa2 -lrte_pmd_skeleton_event -
> > > lrte_pmd_dpaa_event -lrte_mempool_stack -pthread -lrte_pmd_ccp -
> > > lrte_pmd_octeontx_compress -lrte_pmd_sw_event
> > > -lrte_mempool_octeontx -Wl,-
> > > Bdynamic -lrte_pmd_dpaa_sec -lrte_pmd_atlantic
> > > -lrte_pmd_octeontx_event -
> > > lrte_pmd_avp -lrte_bus_pci -lrte_pmd_dpaa2_cmdif -lrte_pmd_mlx5 -
> > > lrte_pmd_opdl_event -lrte_pmd_tap -lrte_pmd_caam_jr -lrte_pmd_sfc
> > > -lcrypto
> > > -lrte_pmd_enetc -lrte_mempool_dpaa2 -lrte_pmd_dpaa2_event
> > > -lrte_pmd_ifc -
> > > lrte_pmd_liquidio -lrte_pmd_cxgbe -lm -lrte_pmd_enic -lrte_bus_vdev
> > > -
> > > lrte_pmd_e1000 -lrte_pmd_softnic -lrte_pmd_ifpga_rawdev
> > > -lrte_bus_vmbus -
> > > lrte_pmd_octeontx_crypto -lrte_pmd_null -lnuma -lrte_common_cpt -
> > > lrte_pmd_nfp -lrte_pmd_qede -lrte_pmd_i40e -lrte_pmd_dpaa -Wl,
> > > --whole-
> > > archive -lrte_pmd_bbdev_null -lrte_pmd_af_packet -lrte_pmd_thunderx
> > > -
> > > lrte_pmd_openssl -lrte_pmd_octeontx -lrte_pmd_dsw_event -Wl,--no-
> > > whole-
> > > archive -lrte_pmd_ring -lrte_pmd_virtio_crypto
> > 
> > That is strange. Can you try one last thing - can you update meson
> > with "pip3 install --upgrade meson" and see if that makes any
> > difference? [If you are using your distro's meson from /usr/bin right
> > now, you'll probably also need to run "hash meson" afterwards too].
> > Perhaps we have a hidden dependency on later meson versions or
> > something like that.
> > 
> > /Bruce
> 
> We do - I can reproduce the same issue with 0.45.1, while normally I
> run 0.47.2. Should we bump the minimum version? Or simply document it?
> 
Bumping the minimum version would be really nice generally for DPDK, but I
don't think this is the point in the release cycle to do so. I need to try
and track down why this is broken with older mesons - most version specific
things are harmless, and I'd like to keep it that way! 

If we can't fix this in rc4, then document, I suggest. That way we don't
require absolutely everyone to use bleeding-edge meson.

/Bruce

Re: [dpdk-dev] [PATCH 1/1] eal: Don't fail secondary if primary is missing tailqs

[Burdick, Cliff]

-----Original Message-----
From: Bruce Richardson [mailto:bruce.richardson@intel.com] 
Sent: Thursday, November 15, 2018 9:17 AM
To: Luca Boccassi
Cc: Burdick, Cliff; Thomas Monjalon; Burakov, Anatoly; dev@dpdk.org
Subject: Re: [dpdk-dev] [PATCH 1/1] eal: Don't fail secondary if primary is missing tailqs

> On Thu, Nov 15, 2018 at 05:05:16PM +0000, Luca Boccassi wrote:
> > On Thu, 2018-11-15 at 17:01 +0000, Richardson, Bruce wrote:
> > > > -----Original Message-----
> > > > From: Burdick, Cliff [mailto:Cliff.Burdick@viasat.com]
> > > > Sent: Thursday, November 15, 2018 4:55 PM
> > > > To: Richardson, Bruce <bruce.richardson@intel.com>
> > > > Cc: Luca Boccassi <bluca@debian.org>; Thomas Monjalon
> > > > <thomas@monjalon.net>; Burakov, Anatoly <anatoly.burakov@intel.com>
> > > > ;
> > > > dev@dpdk.org
> > > > Subject: RE: [dpdk-dev] [PATCH 1/1] eal: Don't fail secondary if
> > > > primary
> > > > is missing tailqs
> > > > 
> > > > 
> > > > 
> > > > -----Original Message-----
> > > > From: Bruce Richardson [mailto:bruce.richardson@intel.com]
> > > > Sent: Thursday, November 15, 2018 8:41 AM
> > > > To: Burdick, Cliff
> > > > Cc: Luca Boccassi; Thomas Monjalon; Burakov, Anatoly; dev@dpdk.org
> > > > Subject: Re: [dpdk-dev] [PATCH 1/1] eal: Don't fail secondary if
> > > > primary
> > > > is missing tailqs
> > > > 
> > > > > On Thu, Nov 15, 2018 at 04:15:36PM +0000, Burdick, Cliff wrote:
> > > > > > 
> > > > > > 
> > > > > > -----Original Message-----
> > > > > > From: Luca Boccassi [mailto:bluca@debian.org]
> > > > > > Sent: Thursday, November 15, 2018 1:33 AM
> > > > > > To: Burdick, Cliff; Bruce Richardson
> > > > > > Cc: Thomas Monjalon; Burakov, Anatoly; dev@dpdk.org
> > > > > > Subject: Re: [dpdk-dev] [PATCH 1/1] eal: Don't fail secondary
> > > > > > if
> > > > > > primary is missing tailqs
> > > > > > 
> > > > > > > On Wed, 2018-11-14 at 18:24 +0000, Burdick, Cliff wrote:
> > > > > > > > 
> > > > > > > > -----Original Message-----
> > > > > > > > From: Luca Boccassi [mailto:bluca@debian.org]
> > > > > > > > Sent: Wednesday, November 14, 2018 10:15 AM
> > > > > > > > To: Burdick, Cliff; Bruce Richardson
> > > > > > > > Cc: Thomas Monjalon; Burakov, Anatoly; dev@dpdk.org
> > > > > > > > Subject: Re: [dpdk-dev] [PATCH 1/1] eal: Don't fail
> > > > > > > > secondary if
> > > > > > > > primary is missing tailqs
> > > > > > > > 
> > > > > > > > > On Wed, 2018-11-14 at 17:40 +0000, Burdick, Cliff wrote:
> > > > > > > > > > 
> > > > > > > > > > -----Original Message-----
> > > > > > > > > > From: Bruce Richardson [mailto:bruce.richardson@intel.c
> > > > > > > > > > om]
> > > > > > > > > > Sent: Wednesday, November 14, 2018 3:48 AM
> > > > > > > > > > To: Burdick, Cliff
> > > > > > > > > > Cc: Thomas Monjalon; Burakov, Anatoly; dev@dpdk.org
> > > > > > > > > > Subject: Re: [dpdk-dev] [PATCH 1/1] eal: Don't fail
> > > > > > > > > > secondary
> > > > > > > > > > if primary is missing tailqs
> > > > > > > > > > 
> > > > > > > > > > On Tue, Nov 13, 2018 at 11:42:51PM +0000, Burdick,
> > > > > > > > > > Cliff
> > > > 
> > > > wrote:
> > > > > > > > > > > > 
> > > > > > > > > > > > ________________________________________
> > > > > > > > > > > > From: Thomas Monjalon [thomas@monjalon.net]
> > > > > > > > > > > > Sent: Tuesday, November 13, 2018 2:18 PM
> > > > > > > > > > > > To: Burdick, Cliff
> > > > > > > > > > > > Cc: Burakov, Anatoly; dev@dpdk.org;
> > > > > > > > > > > > bruce.richardson@intel.co m
> > > > > > > > > > > > Subject: Re: [dpdk-dev] [PATCH 1/1] eal: Don't fail
> > > > > > > > > > > > secondary if primary is missing tailqs
> > > > > > > > > > > > 
> > > > > > > > > > > > 13/11/2018 23:08, Burdick, Cliff:
> > > > > > > > > > > > > From: Thomas Monjalon [mailto:thomas@monjalon.net
> > > > > > > > > > > > > ]
> > > > > > > > > > > > > > 13/11/2018 17:38, Burdick, Cliff:
> > > > > > > > > > > > > > > From: Thomas Monjalon [mailto:thomas@monjalon
> > > > > > > > > > > > > > > .net]
> > > > > > > > > > > > > > > 13/11/2018 16:45, Burdick, Cliff:
> > > > > > > > > > > > > > > > From: Burakov, Anatoly
> > > > 
> > > > [mailto:anatoly.burakov@intel.
> > > > > > > > > > > > > > > > com]
> > > > > > > > > > > > > > > > > On 13-Nov-18 9:21 AM, Thomas Monjalon
> > > > > > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > > > > > 13/11/2018 00:33, Burdick, Cliff:
> > > > > > > > > > > > > > > > > > > This patch was submitted by Jean
> > > > > > > > > > > > > > > > > > > Tourrilhes
> > > > > > > > > > > > > > > > > > > over two years ago, but didn't
> > > > > > > > > > > > > > > > > > > receive any
> > > > 
> > > > responses.
> > > > > > > > > > > > > > > > > > > I hit the same issue recently when
> > > > > > > > > > > > > > > > > > > trying to
> > > > > > > > > > > > > > > > > > > use cgo
> > > > > > > > > > > > > > > > > > > (Golang) as a primary process linked
> > > > > > > > > > > > > > > > > > > to
> > > > > > > > > > > > > > > > > > > libdpdk.a against a C++ application
> > > > > > > > > > > > > > > > > > > linked
> > > > > > > > > > > > > > > > > > > against the same library.> > >
> > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > The question is to know why you don't
> > > > > > > > > > > > > > > > > > have the
> > > > > > > > > > > > > > > > > > same constructors in primary and
> > > > > > > > > > > > > > > > > > seconday?
> > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > I've hit similar things in the past. I
> > > > > > > > > > > > > > > > > believe
> > > > > > > > > > > > > > > > > it was caused by our build system
> > > > > > > > > > > > > > > > > stripping out
> > > > > > > > > > > > > > > > > unused libraries (such as
> > > > > > > > > > > > > > > > > rte_hash) from the binary and thus not
> > > > > > > > > > > > > > > > > calling
> > > > > > > > > > > > > > > > > the constructor in the primary, but doing
> > > > > > > > > > > > > > > > > so in
> > > > > > > > > > > > > > > > > the secondary (or something to that
> > > > > > > > > > > > > > > > > effect). In
> > > > > > > > > > > > > > > > > any case, this is caused by linking
> > > > > > > > > > > > > > > > > different
> > > > > > > > > > > > > > > > > number of libraries to primary and
> > > > > > > > > > > > > > > > > secondary,
> > > > > > > > > > > > > > > > > and should probably be fixed in the build
> > > > > > > > > > > > > > > > > system, not in the tailqs code (unless we
> > > > > > > > > > > > > > > > > specifically support having different
> > > > > > > > > > > > > > > > > linked
> > > > > > > > > > > > > > > > > libraries to primary and secondary?).> >
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > Right, I think the original author of the
> > > > > > > > > > > > > > > > patch
> > > > > > > > > > > > > > > > stated the reasons in the link I provided.
> > > > > > > > > > > > > > > > The
> > > > > > > > > > > > > > > > build system seems like the most
> > > > > > > > > > > > > > > > appropriate place
> > > > > > > > > > > > > > > > to fix it, but the patch got me going
> > > > > > > > > > > > > > > > quickly. I
> > > > > > > > > > > > > > > > think the question is whether you want DPDK
> > > > > > > > > > > > > > > > to
> > > > > > > > > > > > > > > > support these other ways of linking.
> > > > > > > > > > > > > > > > I'm
> > > > > > > > > > > > > > > > certainly not the first to use cgo, since
> > > > > > > > > > > > > > > > there's
> > > > > > > > > > > > > > > > a virtual switch project doing the same:
> > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > https://urldefense.proofpoint.com/v2/url?u=
> > > > > > > > > > > > > > > > https-3
> > > > > > > > > > > > > > > > A__
> > > > > > > > > > > > > > > > gith
> > > > > > > > > > > > > > > > ub.co
> > > > > > > > > > > > > > > > m_lago
> > > > > > > > > > > > > > > > pu
> > > > > > > > > > > > > > > > s_vsw&d=DwICAg&c=jcv3orpCsv7C4ly8-
> > > > > > > > > > > > > > > > ubDoUfrxF5xIGWmptxGWP5vi5w&r =m1RLQ OG
> > > > > > > > > > > > > > > > Okz9MauvVLZmiGtyWc5mA7DejbPFNE1IDj-
> > > > > > > > > > > > > > > > 4&m=hQqVCNwW7eoEzB_hLFK97i8 idS8FI qX
> > > > > > > > > > > > > > > > oPeclwsIZq7Y&s=BMoBlwkqljwWIBY3SE3pPMCfVnOU
> > > > > > > > > > > > > > > > lDuZLrn
> > > > > > > > > > > > > > > > o4-
> > > > > > > > > > > > > > > > SojKM&e=
> > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > They don't use primary/secondary processes,
> > > > > > > > > > > > > > > > though, so the issue is  never hit. I'm in
> > > > > > > > > > > > > > > > a
> > > > > > > > > > > > > > > > situation where using cgo seemed like the
> > > > > > > > > > > > > > > > easiest
> > > > > > > > > > > > > > > > path to accomplish what I'm doing since I
> > > > > > > > > > > > > > > > needed
> > > > > > > > > > > > > > > > specialized  libraries for it that were not
> > > > > > > > > > > > > > > > available in C/C++. At some point I  bet
> > > > > > > > > > > > > > > > someone
> > > > > > > > > > > > > > > > would use Cython to start linking against
> > > > > > > > > > > > > > > > DPDK as
> > > > > > > > > > > > > > > > well,  and we'd likely run into the same
> > > > > > > > > > > > > > > > issue.> >
> > > > > > > > > > > > > > > > > > For sure, we want to support using DPDK
> > > > > > > > > > > > > > > > > > with
> > > > 
> > > > cgo or cython.
> > > > > > > > > > > > > > > > But it is not clear what is the relation
> > > > > > > > > > > > > > > > with not
> > > > > > > > > > > > > > > > having the same compilation for primary and
> > > > 
> > > > secondary.
> > > > > > > > > > > > > > > > Please
> > > > > > > > > > > > > > > > could you elaborate?> > >
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > Hi Thomas, I think Jean explained it well
> > > > > > > > > > > > > > > here:
> > > > > > > > > > > > > > > https://urldefense.proofpoint.com/v2/url?u=ht
> > > > > > > > > > > > > > > tps-3A_
> > > > > > > > > > > > > > > _de
> > > > > > > > > > > > > > > v.dp
> > > > > > > > > > > > > > > dk.narkive.
> > > > > > > > > > > > > > > com_ZM3a7QD1_dpdk-2Ddev-2Dbug-2Dstatic-
> > > > > > > > > > > > > > > 2Dconstructor
> > > > > > > > > > > > > > > s-
> > > > > > > > > > > > > > > 2Dconsider
> > > > > > > > > > > > > > > ed-2De
> > > > > > > > > > > > > > > vil&d=DwICAg&c=jcv3orpCsv7C4ly8-
> > > > > > > > > > > > > > > ubDoUfrxF5xIGWmptxGWP5vi5w&r=m1R LQOGOk
> > > > > > > > > > > > > > > z9MauvVLZmiGtyWc5mA7DejbPFNE1IDj-
> > > > > > > > > > > > > > > 4&m=C69wDgrjDX8_oXp1M_3bnmWOOZd GqwBBG
> > > > > > > > > > > > > > > 9vzkyGDWGQ&s=YYn2N7WrzJpH1ptNrLZad0nPAQdrUyqB
> > > > > > > > > > > > > > > ckk2uFu
> > > > > > > > > > > > > > > WYP
> > > > > > > > > > > > > > > Q&e=
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > "The build system of the application does not
> > > > > > > > > > > > > > > have
> > > > > > > > > > > > > > > all the subtelties of the DPDK build system,
> > > > > > > > > > > > > > > and
> > > > > > > > > > > > > > > ends up including
> > > > > > > > > > > > > > > *all*
> > > > > > > > > > > > > > > the constructors, wether they are used or not
> > > > > > > > > > > > > > > in the
> > > > > > > > > > > > > > > code.
> > > > > > > > > > > > > > > Moreover, they are included in a different
> > > > > > > > > > > > > > > order.
> > > > > > > > > > > > > > > Actually,
> > > > > > > > > > > > > > > by default the builds include no constructors
> > > > > > > > > > > > > > > at all
> > > > > > > > > > > > > > > (which is a big fail), so the library needs
> > > > > > > > > > > > > > > to be
> > > > > > > > > > > > > > > included with --whole-archive (see Snort DPDK
> > > > > > > > > > > > > > > instructions)."
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > I will get to the bottom of my exact case to
> > > > > > > > > > > > > > > understand what's happening, but my primary
> > > > > > > > > > > > > > > application is a cgo application that I'm
> > > > > > > > > > > > > > > linking to
> > > > > > > > > > > > > > > by using almost exactly the same flags that
> > > > > > > > > > > > > > > are used
> > > > > > > > > > > > > > > in the DPDK build system to build examples.
> > > > > > > > > > > > > > > The DPDK
> > > > > > > > > > > > > > > libraries I'm linking against is a single
> > > > > > > > > > > > > > > location
> > > > > > > > > > > > > > > for both primary and secondary; in other
> > > > > > > > > > > > > > > words, I
> > > > 
> > > > don't build DPDK twice.
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > OK I understand, thanks.
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > You had alluded to a pkg-config for DPDK in
> > > > > > > > > > > > > > > the 2015
> > > > > > > > > > > > > > > thread, which cgo can use, but I don't know
> > > > > > > > > > > > > > > if that
> > > > > > > > > > > > > > > ever was implemented. Cgo can use pkg-config
> > > > > > > > > > > > > > > if it's
> > > > > > > > > > > > > > > available, otherwise the only tools are
> > > > > > > > > > > > > > > specifying
> > > > > > > > > > > > > > > LDFLAGS and CFLAGS into their build system.
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > Yes, the right answer is still pkg-config :)
> > > > > > > > > > > > > > The good
> > > > > > > > > > > > > > news is that it is now implemented thanks to
> > > > > > > > > > > > > > the meson
> > > > > > > > > > > > > > build
> > > > > > > > > > > > > > system:
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > https://urldefense.proofpoint.com/v2/url?u=http
> > > > > > > > > > > > > > -3A__gi
> > > > > > > > > > > > > > t.d
> > > > > > > > > > > > > > pdk.
> > > > > > > > > > > > > > org_dp
> > > > > > > > > > > > > > dk_tree_doc_build-2Dsdk-2Dmeson.txt-
> > > > > > > > > > > > > > 23n182&d=DwICAg&c=jcv3orpCsv7C4
> > > > > > > > > > > > > > ly8-
> > > > > > > > > > > > > > ubDoUfrxF5xIGWmptxGWP5vi5w&r=m1RLQOGOkz9MauvVLZ
> > > > > > > > > > > > > > miGtyWc
> > > > > > > > > > > > > > 5mA
> > > > > > > > > > > > > > 7Dej
> > > > > > > > > > > > > > bP
> > > > > > > > > > > > > > FNE1IDj-
> > > > > > > > > > > > > > > 4&m=C69wDgrjDX8_oXp1M_3bnmWOOZdGqwBBG9vzkyGDW
> > > > > > > > > > > > > > > GQ&s=oC
> > > > > > > > > > > > > > > 86K
> > > > > > > > > > > > > > > D_R
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > J1T6rfzi3x5zFT1Ri13ELpKmsyFqpgDbgFg&e=
> > > > > > > > > > > > > 
> > > > > > > > > > > > > Hi Thomas, are there instructions on how to use
> > > > > > > > > > > > > pkg-config to build the mlx4/5 PMD? I noticed a
> > > > > > > > > > > > > patch
> > > > > > > > > > > > > was submitted in September to add support for it,
> > > > > > > > > > > > > but
> > > > > > > > > > > > > that link you provided on using meson doesn't say
> > > > > > > > > > > > > how to
> > > > > > > > > > > > > build specific drivers. It appears to be disabled
> > > > > > > > > > > > > by
> > > > 
> > > > default.
> > > > > > > > > > > > > If the dependency is found, meson will enable the
> > > > > > > > > > > > > PMD
> > > > > > > > > > > > > when building DPDK.
> > > > > > > > > > > > 
> > > > > > > > > > > > Do you know where exactly that is? I've been using
> > > > > > > > > > > > mlx5
> > > > > > > > > > > > for a while on this system, and I can see that
> > > > > > > > > > > > 18.11-rc2
> > > > > > > > > > > > meson
> > > > > > > > > > > > build+ninja built the pmd, but it's not on the --
> > > > > > > > > > > > libs
> > > > > > > > > > > > build+listing
> > > > > > > > > > > > for
> > > > > > > > > > > > pkg-config. Does it tell me what I was missing?
> > > > > > > > > > > > 
> > > > > > > > > > > 
> > > > > > > > > > > For dynamic linking of applications, the drivers are
> > > > > > > > > > > not
> > > > > > > > > > > normally linked in. Instead, they should be loaded
> > > > > > > > > > > from the
> > > > > > > > > > > drivers directory as .so files
> > > > > > > > > > > - normally by default in EAL as the driver .so's
> > > > > > > > > > > should be
> > > > > > > > > > > copied to the EAL_PMD_PATH where EAL finds them
> > > > 
> > > > automatically.
> > > > > > > > > > > [This applies to both meson and make builds, though
> > > > > > > > > > > only
> > > > > > > > > > > meson generates the .pc file for pkg-config]
> > > > > > > > > > > 
> > > > > > > > > > > If you are doing a static build, then you need to
> > > > > > > > > > > explicitly
> > > > > > > > > > > link in the drivers. You can get a list from pkg-
> > > > > > > > > > > config
> > > > > > > > > > > using the "
> > > > > > > > > > > --static" flag in this case. A good example of how to
> > > > > > > > > > > use
> > > > > > > > > > > pkg- config in this way can be found in the Makefiles
> > > > > > > > > > > for
> > > > > > > > > > > most examples, e.g. examples/helloworld/Makefile,
> > > > > > > > > > > reproduced
> > > > 
> > > > below.
> > > > > > > > > > > 
> > > > > > > > > > > Regards,
> > > > > > > > > > > /Bruce
> > > > > > > > > > > 
> > > > > > > > > > > all: shared
> > > > > > > > > > > .PHONY: shared static
> > > > > > > > > > > shared: build/$(APP)-shared
> > > > > > > > > > >         ln -sf $(APP)-shared build/$(APP)
> > > > > > > > > > > static: build/$(APP)-static
> > > > > > > > > > >         ln -sf $(APP)-static build/$(APP)
> > > > > > > > > > > 
> > > > > > > > > > > PC_FILE := $(shell pkg-config --path libdpdk) CFLAGS
> > > > > > > > > > > += -O3
> > > > > > > > > > > $(shell pkg-config --cflags libdpdk) LDFLAGS_SHARED =
> > > > > > > > > > > $(shell
> > > > > > > > > > > pkg- config -- libs libdpdk) LDFLAGS_STATIC = -Wl,-
> > > > > > > > > > > Bstatic
> > > > > > > > > > > $(shell pkg-config
> > > > > > > > > > > --
> > > > > > > > > > > static --libs libdpdk)
> > > > > > > > > > > 
> > > > > > > > > > > build/$(APP)-shared: $(SRCS-y) Makefile $(PC_FILE) |
> > > > > > > > > > > build
> > > > > > > > > > >         $(CC) $(CFLAGS) $(SRCS-y) -o $@ $(LDFLAGS)
> > > > > > > > > > > $(LDFLAGS_SHARED)
> > > > > > > > > > > 
> > > > > > > > > > > build/$(APP)-static: $(SRCS-y) Makefile $(PC_FILE) |
> > > > > > > > > > > build
> > > > > > > > > > >         $(CC) $(CFLAGS) $(SRCS-y) -o $@ $(LDFLAGS)
> > > > > > > > > > > $(LDFLAGS_STATIC)
> > > > > > > > > > > 
> > > > > > > > > > > build:
> > > > > > > > > > >         @mkdir -p $@
> > > > > > > > > > 
> > > > > > > > > > Thanks Bruce. I tried getting this to compile using
> > > > > > > > > > cgo, and
> > > > > > > > > > it's causing more pain than it's worth. I used the --
> > > > > > > > > > static
> > > > > > > > > > --libs options, and there were still numerous linker
> > > > > > > > > > errors,
> > > > > > > > > > some specific to mlx, and some not. Specifically
> > > > > > > > > > libmlx5 and
> > > > > > > > > > libmnl are both needed, but they're not part of the
> > > > > > > > > > linker
> > > > > > > > > > line from pkg-config. At this point I'll just break the
> > > > > > > > > > Go
> > > > > > > > > > application up into a separate C application that
> > > > > > > > > > handles all
> > > > > > > > > > the DPDK parts, and send messages between them.
> > > > > > > > > 
> > > > > > > > > Hi,
> > > > > > > > > 
> > > > > > > > > As far as I can see, both mnl and mlx5 (and all the other
> > > > > > > > > reverse
> > > > > > > > > dependencies) are listed correctly in the libdpdk.pc
> > > > > > > > > Libs.private entry, and pkg-config --libs --static
> > > > > > > > > libdpdk.pc
> > > > > > > > > does print them as intended. This is with 18.11-rc3.
> > > > > > > > > Are you sure everything is correct (pkg-config path is
> > > > > > > > > right, --
> > > > > > > > > static is used, etc)?
> > > > > > > > > 
> > > > > > > > > --
> > > > > > > > > Kind regards,
> > > > > > > > > Luca Boccassi
> > > > > > > > 
> > > > > > > > Hi Luca, here is what pkg-config gives:
> > > > > > > > 
> > > > > > > > PKG_CONFIG_PATH=meson-private/ pkg-config --libs --static
> > > > > > > > libdpdk
> > > > > > > > -L/usr/local/lib/x86_64-linux-gnu -lrte_eventdev
> > > > > > > > -lrte_power
> > > > > > > > -lrte_ip_frag -lrte_hash -lrte_pdump -lrte_eal
> > > > > > > > -lrte_pipeline
> > > > > > > > -lrte_table -lrte_bbdev -lrte_bpf -lrte_vhost -lrte_metrics
> > > > > > > > -lrte_jobstats -lrte_net -lrte_reorder -lrte_ring
> > > > > > > > -lrte_mempool
> > > > > > > > -lrte_security -lrte_compressdev -lrte_rawdev -lrte_mbuf
> > > > > > > > -lrte_kvargs -lrte_port -lrte_pci -lrte_ethdev -lrte_gro
> > > > > > > > -lrte_gso
> > > > > > > > -lrte_cryptodev -lrte_sched -lrte_latencystats -lrte_efd
> > > > > > > > -lrte_distributor -lrte_meter -lrte_acl -lrte_member
> > > > > > > > -lrte_cmdline
> > > > > > > > -lrte_lpm -lrte_kni -lrte_cfgfile -lrte_bitratestats
> > > > > > > > -lrte_timer
> > > > > > > > -lrte_flow_classify -lrte_mempool_bucket
> > > > > > > > -lrte_pmd_null_crypto
> > > > > > > > -lrte_pmd_failsafe -lrte_bus_ifpga -lrte_pmd_atlantic
> > > > > > > > -lrte_pmd_mlx4 -lrte_pmd_vmxnet3 -lrte_pmd_avp
> > > > > > > > -lrte_common_dpaax
> > > > > > > > -lrte_pmd_ena -lcrypto -lrte_bus_fslmc -ldl -lrte_pmd_avf
> > > > > > > > -lrte_pmd_crypto_scheduler -lrte_pmd_netvsc -lrte_pmd_vhost
> > > > > > > > -lrte_bus_dpaa -lrte_mempool_dpaa2 -lrte_common_octeontx
> > > > > > > > -lrte_pmd_liquidio -lrte_pmd_ifc -Wl,-Bdynamic -lnuma
> > > > > > > > -lrte_pmd_enic -lrte_common_cpt -pthread
> > > > > > > > -lrte_pmd_octeontx_crypto
> > > > > > > > -lrte_pmd_qat -lrte_bus_vmbus -lrte_pmd_null -lm
> > > > > > > > -lrte_pmd_dpaa
> > > > > > > > -lrte_bus_vdev -lrte_pmd_dpaa2 -lrte_pmd_skeleton_event
> > > > > > > > -lrte_pmd_af_packet -lrte_pmd_octeontx -lrte_pmd_thunderx
> > > > > > > > -lrte_pmd_ring -lrte_pmd_octeontx_event -lrte_pmd_sw_event
> > > > > > > > -lrte_pmd_ark -lrte_mempool_octeontx -lrte_pmd_ixgbe
> > > > > > > > -lrte_pmd_kni
> > > > > > > > -lrte_mempool_ring -lrte_pmd_virtio_crypto
> > > > > > > > -lrte_mempool_dpaa
> > > > > > > > -lrte_pmd_dpaa2_cmdif -lrte_bus_pci -lrte_pmd_opdl_event
> > > > > > > > -lrte_pmd_mlx5 -lrte_pmd_virtio -lrte_pmd_tap
> > > > > > > > -lrte_pmd_caam_jr
> > > > > > > > -lrte_pmd_dpaa2_sec -lrte_pmd_dpaa2_qdma -lrte_pmd_enetc
> > > > > > > > -lrte_pmd_sfc -lrte_pmd_bnxt -lrte_pmd_dpaa2_event
> > > > > > > > -lrte_pmd_cxgbe
> > > > > > > > -Wl,--whole-archive -Wl,--no- as-needed -lrte_pmd_e1000
> > > > > > > > -lrte_pmd_softnic -lrte_pmd_bond -lrte_pmd_fm10k
> > > > > > > > -lrte_pmd_i40e
> > > > > > > > -lrte_pmd_nfp -lrte_pmd_qede -Wl,--no- whole-archive
> > > > > > > > -lrte_pmd_axgbe -lrte_pmd_ccp -lrte_pmd_ifpga_rawdev
> > > > > > > > -lrte_pmd_bbdev_null -lrte_pmd_openssl -lrte_pmd_dsw_event
> > > > > > > > -lrte_pmd_dpaa_event -lrte_mempool_stack
> > > > > > > > -lrte_pmd_vdev_netvsc
> > > > > > > > -lrte_pmd_dpaa_sec -lrte_pmd_skeleton_rawdev
> > > > > > > > -lrte_pmd_octeontx_compress
> > > > > > > > 
> > > > > > > > You'll notice there's no mlx5 or mnl in that list. I was
> > > > > > > > using
> > > > > > > > 18.11-
> > > > > > > > rc2 since I cloned early yesterday. Perhaps meson
> > > > > > > > determined not
> > > > > > > > to put it in there for some reason?
> > > > > > > 
> > > > > > > Were mlx5/mnl found at meson configure time?
> > > > > > > 
> > > > > > > --
> > > > > > > Kind regards,
> > > > > > > Luca Boccassi
> > > > > > 
> > > > > > Hi Luca, yes, it was:
> > > > > > 
> > > > > > Library mnl found: YES
> > > > > > Library mlx4 found: YES
> > > > > > Library ibverbs found: YES
> > > > > > Compiler for C supports argument -Wextra: YES Compiler for C
> > > > > > supports
> > > > > > argument -std=c11: YES Compiler for C supports argument
> > > > > > -Wno-strict-prototypes: YES Compiler for C supports argument
> > > > > > -D_BSD_SOURCE: YES Compiler for C supports argument
> > > > > > -D_DEFAULT_SOURCE:
> > > > > > YES Compiler for C supports argument -D_XOPEN_SOURCE=600: YES
> > > > > > Checking
> > > > > > whether type "struct mlx4_wqe_lso_seg" has member
> > > > > > "mss_hdr_size": YES
> > > > > > Configuring mlx4_autoconf.h using configuration Library mnl
> > > > > > found: YES
> > > > > > Library mlx5 found: YES Library ibverbs found: YES ...
> > > > > > PKG_CONFIG_PATH=meson-private/ pkg-config --libs --static
> > > > > > libdpdk
> > > > > > -L/usr/local/lib/x86_64-linux-gnu -lrte_eventdev -lrte_power
> > > > > > -lrte_ip_frag -lrte_hash -lrte_pdump -lrte_eal -lrte_pipeline
> > > > > > -lrte_table -lrte_bbdev -lrte_bpf -lrte_vhost -lrte_metrics
> > > > > > -lrte_jobstats -lrte_net -lrte_reorder -lrte_ring -lrte_mempool
> > > > > > -lrte_security -lrte_compressdev -lrte_rawdev -lrte_mbuf
> > > > > > -lrte_kvargs
> > > > > > -lrte_port -lrte_pci -lrte_ethdev -lrte_gro -lrte_gso
> > > > > > -lrte_cryptodev
> > > > > > -lrte_sched -lrte_latencystats -lrte_efd -lrte_distributor
> > > > > > -lrte_meter
> > > > > > -lrte_acl -lrte_member -lrte_cmdline -lrte_lpm -lrte_kni
> > > > > > -lrte_cfgfile
> > > > > > -lrte_bitratestats -lrte_timer -lrte_flow_classify
> > > > > > -lrte_pmd_ccp
> > > > > > -lrte_mempool_bucket -lrte_pmd_failsafe -lrte_pmd_netvsc
> > > > > > -lrte_pmd_null_crypto -lrte_bus_ifpga -lrte_pmd_atlantic
> > > > > > -lrte_pmd_octeontx_event -lrte_pmd_avp -lrte_pmd_mlx4
> > > > > > -lrte_common_dpaax -lrte_pmd_skeleton_rawdev -lrte_pmd_ena
> > > > > > -lrte_pmd_opdl_event -lrte_bus_fslmc -lnuma -lrte_pmd_avf
> > > > > > -lrte_pmd_crypto_scheduler -lrte_pmd_vhost -lrte_bus_dpaa
> > > > > > -lrte_mempool_dpaa2 -lrte_common_octeontx -Wl,--no-as-needed
> > > > > > -lcrypto
> > > > > > -lrte_pmd_ifc -lrte_pmd_liquidio -lrte_pmd_enic
> > > > > > -lrte_common_cpt
> > > > > > -Wl,--no-whole-archive -lrte_bus_vmbus
> > > > > > -lrte_pmd_octeontx_crypto
> > > > > > -lrte_pmd_qat -lrte_pmd_ifpga_rawdev -lrte_pmd_dpaa
> > > > > > -lrte_bus_vdev
> > > > > > -lrte_pmd_bbdev_null -lrte_pmd_dpaa2 -lrte_pmd_skeleton_event
> > > > > > -lrte_pmd_ring -lrte_pmd_af_packet -lrte_pmd_thunderx
> > > > > > -lrte_pmd_dpaa_event -lrte_pmd_octeontx_compress
> > > > > > -lrte_pmd_dpaa_sec
> > > > > > -lrte_pmd_sw_event -Wl,--whole-archive -lrte_pmd_ark
> > > > > > -lrte_mempool_octeontx -lrte_pmd_ixgbe -lrte_mempool_ring
> > > > > > -lrte_pmd_kni -lrte_pmd_vmxnet3 -lrte_mempool_dpaa
> > > > > > -lrte_bus_pci
> > > > > > -lrte_pmd_dpaa2_cmdif -lrte_pmd_mlx5 -lrte_pmd_tap
> > > > > > -lrte_pmd_caam_jr
> > > > > > -lrte_pmd_dpaa2_sec -lm -lrte_pmd_dpaa2_qdma -lrte_pmd_enetc
> > > > > > -lrte_pmd_virtio -lrte_pmd_bnxt -lrte_pmd_dpaa2_event
> > > > > > -lrte_pmd_sfc
> > > > > > -lrte_pmd_cxgbe -pthread -lrte_pmd_e1000 -lrte_pmd_softnic -ldl
> > > > > > -lrte_pmd_null -lrte_pmd_bond -lrte_pmd_fm10k -lrte_pmd_i40e
> > > > > > -lrte_pmd_nfp -lrte_pmd_qede -lrte_pmd_axgbe -Wl,-Bdynamic
> > > > > > -lrte_pmd_openssl -lrte_pmd_octeontx -lrte_pmd_dsw_event
> > > > > > -lrte_mempool_stack -lrte_pmd_virtio_crypto
> > > > > > -lrte_pmd_vdev_netvsc
> > > > > 
> > > > > Is this with latest DPDK from git? because I see the exact same
> > > > > as Luca:
> > > > > 
> > > > > $ PKG_CONFIG_PATH=build/meson-private/ pkg-config --libs --static
> > > > 
> > > > libdpdk | grep mlx
> > > > > -L/usr/local/lib64 -lrte_telemetry -lrte_bpf -lrte_flow_classify
> > > > > -
> > > > 
> > > > lrte_pipeline -lrte_table -lrte_port -lrte_vhost -lrte_security -
> > > > lrte_sched -lrte_reorder -lrte_rawdev -lrte_pdump -lrte_power
> > > > -lrte_meter
> > > > -lrte_member -lrte_lpm -lrte_latencystats -lrte_kni -lrte_jobstats
> > > > -
> > > > lrte_ip_frag -lrte_gso -lrte_gro -lrte_eventdev -lrte_efd -
> > > > lrte_distributor -lrte_cryptodev -lrte_compressdev -lrte_cfgfile -
> > > > lrte_bitratestats -lrte_bbdev -lrte_acl -lrte_timer -lrte_hash -
> > > > lrte_metrics -lrte_pci -lrte_ethdev -lrte_net -lrte_mbuf
> > > > -lrte_mempool -
> > > > lrte_ring -lrte_eal -lrte_kvargs -lrte_cmdline -L/usr/local/lib64 -
> > > > lrte_kvargs -lrte_eal -lrte_ring -lrte_mempool -lrte_mbuf -lrte_pci
> > > > -
> > > > lrte_cryptodev -lrte_net -lrte_cmdline -lrte_ethdev -lrte_hash
> > > > -lrte_timer
> > > > -lrte_common_dpaax -lrte_eventdev -lrte_rawdev -lrte_bus_dpaa -
> > > > lrte_bus_fslmc -lrte_bus_pci -lrte_common_octeontx -lrte_bus_vdev -
> > > > lrte_meter -lrte_sched -lrte_ip_frag -lz -lrte_mempool_dpaa -
> > > > lrte_mempool_dpaa2 -lrte_vhost -lrte_security -lrte_kni -lmnl
> > > > -lmlx4 -
> > > > libverbs -lmnl -lmlx5 -libverbs -lrte_bus_vmbus
> > > > -lrte_mempool_octeontx -
> > > > lpcap -lrte_port -lrte_lpm -lrte_acl -lrte_table -lrte_pipeline
> > > > -lsze2 -
> > > > lrte_gso -lIPSec_MB -lIPSec_MB -lrte_common_cpt -lrte_reorder -
> > > > lrte_compressdev -lrte_pmd_dpaa -lrte_pmd_dpaa2 -lrte_pmd_dpaa2_sec
> > > > -
> > > > lrte_pmd_octeontx -lrte_bbdev -lrte_bus_ifpga -Wl,--whole-archive -
> > > > lrte_mempool_bucket -lrte_mempool_ring -lrte_mempool_stack -
> > > > lrte_pmd_af_packet -lrte_pmd_ark -lrte_pmd_atlantic -lrte_pmd_avf -
> > > > lrte_pmd_avp -lrte_pmd_axgbe -lrte_pmd_bond -lrte_pmd_bnx2x
> > > > -lrte_pmd_bnxt
> > > > -lrte_pmd_cxgbe -lrte_pmd_e1000 -lrte_pmd_ena -lrte_pmd_enetc -
> > > > lrte_pmd_enic -lrte_pmd_failsafe -lrte_pmd_fm10k -lrte_pmd_i40e -
> > > > lrte_pmd_ifc -lrte_pmd_ixgbe -lrte_pmd_kmod -lrte_pmd_kni -
> > > > lrte_pmd_liquidio -lrte_pmd_mlx4 -lrte_pmd_mlx5 -lrte_pmd_netvsc -
> > > > lrte_pmd_nfp -lrte_pmd_null -lrte_pmd_pcap -lrte_pmd_qede
> > > > -lrte_pmd_ring -
> > > > lrte_pmd_sfc -lrte_pmd_softnic -lrte_pmd_szedata2 -lrte_pmd_tap -
> > > > lrte_pmd_thunderx -lrte_pmd_vdev_netvsc -lrte_pmd_vhost
> > > > -lrte_pmd_virtio -
> > > > lrte_pmd_vmxnet3 -lrte_pmd_aesni_gcm -lrte_pmd_aesni_mb
> > > > -lrte_pmd_caam_jr
> > > > -lrte_pmd_ccp -lrte_pmd_dpaa_sec -lrte_pmd_null_crypto -
> > > > lrte_pmd_octeontx_crypto -lrte_pmd_openssl
> > > > -lrte_pmd_crypto_scheduler -
> > > > lrte_pmd_virtio_crypto -lrte_pmd_octeontx_compress -lrte_pmd_qat -
> > > > lrte_pmd_zlib -lrte_pmd_dpaa_event -lrte_pmd_dpaa2_event -
> > > > lrte_pmd_octeontx_event -lrte_pmd_opdl_event
> > > > -lrte_pmd_skeleton_event -
> > > > lrte_pmd_sw_event -lrte_pmd_dsw_event -lrte_pmd_bbdev_null -
> > > > lrte_pmd_skeleton_rawdev -lrte_pmd_dpaa2_cmdif -lrte_pmd_dpaa2_qdma
> > > > -
> > > > lrte_pmd_ifpga_rawdev -lrte_pmd_ioat_copy -Wl,--no-whole-archive
> > > > -Wl,-
> > > > Bdynamic -Wl,--no-as-needed -pthread -lm -ldl -lnuma -lbsd -lpcap
> > > > -lcrypto
> > > > -lcrypto -lz -lcrypto -ldl -pthread -lz
> > > > 
> > > > Hi Bruce, I tried with rc3 and a new clone from right now, and get
> > > > the
> > > > same results:
> > > > 
> > > > $ meson build
> > > > The Meson build system
> > > > Version: 0.45.1
> > > > Source dir: /home/cburdick/dpdk
> > > > Build dir: /home/cburdick/dpdk/build
> > > > Build type: native build
> > > > Project name: DPDK
> > > > Native C compiler: cc (gcc 7.3.0 "cc (Ubuntu 7.3.0-27ubuntu1~18.04)
> > > > 7.3.0")
> > > > Build machine cpu family: x86_64
> > > > Build machine cpu: x86_64
> > > > Library numa found: YES
> > > > Has header "numaif.h": YES
> > > > Library bsd found: NO
> > > > Checking for size of "void *": 8
> > > > Compiler for C supports argument -Wsign-compare: YES
> > > > Compiler for C supports argument -Wcast-qual: YES
> > > > Compiler for C supports argument -Wno-address-of-packed-member: YES
> > > > Fetching value of define "__SSE4_2__": 1
> > > > Fetching value of define "__AES__": 1
> > > > Fetching value of define "__PCLMUL__": 1
> > > > Fetching value of define "__AVX__": 1
> > > > Fetching value of define "__AVX2__": 1
> > > > Fetching value of define "__AVX512F__":
> > > > Compiler for C supports argument -Wno-format-truncation: YES
> > > > Checking for size of "void *": 8
> > > > Has header "linux/userfaultfd.h": YES
> > > > Checking for size of "void *": 8
> > > > Library elf found: NO
> > > > Library jansson found: NO
> > > > Program gen-pmdinfo-cfile.sh found: YES
> > > > (/home/cburdick/dpdk/buildtools/gen-pmdinfo-cfile.sh)
> > > > Compiler for C supports argument -Wno-format-truncation: YES
> > > > Library libmusdk found: NO
> > > > Compiler for C supports argument -Wno-cast-qual: YES
> > > > Compiler for C supports argument -Wno-pointer-to-int-cast: YES
> > > > Library z found: NO
> > > > Compiler for C supports argument -Wno-uninitialized: YES
> > > > Compiler for C supports argument -Wno-unused-parameter: YES
> > > > Compiler for C supports argument -Wno-unused-variable: YES
> > > > Compiler for C supports argument -Wno-misleading-indentation: YES
> > > > Compiler for C supports argument -Wno-implicit-fallthrough: YES
> > > > Checking for size of "void *": 8
> > > > Compiler for C supports argument -Wno-unused-parameter: YES
> > > > Compiler for C supports argument -Wno-unused-value: YES
> > > > Compiler for C supports argument -Wno-strict-aliasing: YES
> > > > Compiler for C supports argument -Wno-format-extra-args: YES
> > > > Compiler for C supports argument -Wno-unused-variable: YES
> > > > Compiler for C supports argument -Wno-missing-field-initializers:
> > > > YES
> > > > Compiler for C supports argument -Wno-sign-compare: YES
> > > > Compiler for C supports argument -Wno-unused-value: YES
> > > > Compiler for C supports argument -Wno-format: YES
> > > > Compiler for C supports argument -Wno-error=format-security: YES
> > > > Compiler for C supports argument -Wno-strict-aliasing: YES
> > > > Compiler for C supports argument -Wno-unused-but-set-variable: YES
> > > > Compiler for C supports argument -Wno-unused-value: YES
> > > > Compiler for C supports argument -Wno-unused-but-set-variable: YES
> > > > Library mnl found: YES
> > > > Library mlx4 found: YES
> > > > Library ibverbs found: YES
> > > > Compiler for C supports argument -Wextra: YES
> > > > Compiler for C supports argument -std=c11: YES
> > > > Compiler for C supports argument -Wno-strict-prototypes: YES
> > > > Compiler for C supports argument -D_BSD_SOURCE: YES
> > > > Compiler for C supports argument -D_DEFAULT_SOURCE: YES
> > > > Compiler for C supports argument -D_XOPEN_SOURCE=600: YES
> > > > Checking whether type "struct mlx4_wqe_lso_seg" has member
> > > > "mss_hdr_size":
> > > > YES
> > > > Configuring mlx4_autoconf.h using configuration
> > > > Library mnl found: YES
> > > > Library mlx5 found: YES
> > > > Library ibverbs found: YES
> > > > Compiler for C supports argument -Wextra: YES
> > > > Compiler for C supports argument -std=c11: YES
> > > > Compiler for C supports argument -Wno-strict-prototypes: YES
> > > > Compiler for C supports argument -D_BSD_SOURCE: YES
> > > > Compiler for C supports argument -D_DEFAULT_SOURCE: YES
> > > > Compiler for C supports argument -D_XOPEN_SOURCE=600: YES
> > > > Header <infiniband/mlx5dv.h> has symbol
> > > > "MLX5DV_CQE_RES_FORMAT_CSUM_STRIDX": YES
> > > > Header <infiniband/mlx5dv.h> has symbol
> > > > "MLX5DV_CONTEXT_MASK_TUNNEL_OFFLOADS": YES
> > > > Header <infiniband/mlx5dv.h> has symbol
> > > > "MLX5DV_CONTEXT_FLAGS_MPW_ALLOWED": YES
> > > > Header <infiniband/mlx5dv.h> has symbol
> > > > "MLX5DV_CONTEXT_FLAGS_CQE_128B_COMP": YES
> > > > Header <infiniband/mlx5dv.h> has symbol
> > > > "MLX5DV_CQ_INIT_ATTR_FLAGS_CQE_PAD": YES
> > > > Header <infiniband/mlx5dv.h> has symbol
> > > > "mlx5dv_create_flow_action_packet_reformat": NO
> > > > Header <infiniband/verbs.h> has symbol "IBV_FLOW_SPEC_MPLS": YES
> > > > Header <infiniband/verbs.h> has symbol
> > > > "IBV_WQ_FLAG_RX_END_PADDING": NO
> > > > Header <linux/ethtool.h> has symbol "SUPPORTED_40000baseKR4_Full":
> > > > YES
> > > > Header <linux/ethtool.h> has symbol "SUPPORTED_40000baseCR4_Full":
> > > > YES
> > > > Header <linux/ethtool.h> has symbol "SUPPORTED_40000baseSR4_Full":
> > > > YES
> > > > Header <linux/ethtool.h> has symbol "SUPPORTED_40000baseLR4_Full":
> > > > YES
> > > > Header <linux/ethtool.h> has symbol "SUPPORTED_56000baseKR4_Full":
> > > > YES
> > > > Header <linux/ethtool.h> has symbol "SUPPORTED_56000baseCR4_Full":
> > > > YES
> > > > Header <linux/ethtool.h> has symbol "SUPPORTED_56000baseSR4_Full":
> > > > YES
> > > > Header <linux/ethtool.h> has symbol "SUPPORTED_56000baseLR4_Full":
> > > > YES
> > > > Header <linux/ethtool.h> has symbol
> > > > "ETHTOOL_LINK_MODE_25000baseCR_Full_BIT": YES
> > > > Header <linux/ethtool.h> has symbol
> > > > "ETHTOOL_LINK_MODE_50000baseCR2_Full_BIT": YES
> > > > Header <linux/ethtool.h> has symbol
> > > > "ETHTOOL_LINK_MODE_100000baseKR4_Full_BIT": YES
> > > > Header <linux/if_link.h> has symbol "IFLA_PHYS_SWITCH_ID": YES
> > > > Header <linux/if_link.h> has symbol "IFLA_PHYS_PORT_NAME": YES
> > > > Header <linux/if_link.h> has symbol "IFLA_VXLAN_COLLECT_METADATA":
> > > > YES
> > > > Header <linux/rtnetlink.h> has symbol "TCA_CHAIN": YES
> > > > Header <linux/pkt_cls.h> has symbol "TCA_FLOWER_ACT": YES
> > > > Header <linux/pkt_cls.h> has symbol "TCA_FLOWER_FLAGS": YES
> > > > Header <linux/pkt_cls.h> has symbol "TCA_FLOWER_KEY_ETH_TYPE": YES
> > > > Header <linux/pkt_cls.h> has symbol "TCA_FLOWER_KEY_ETH_DST": YES
> > > > Header <linux/pkt_cls.h> has symbol "TCA_FLOWER_KEY_ETH_DST_MASK":
> > > > YES
> > > > Header <linux/pkt_cls.h> has symbol "TCA_FLOWER_KEY_ETH_SRC": YES
> > > > Header <linux/pkt_cls.h> has symbol "TCA_FLOWER_KEY_ETH_SRC_MASK":
> > > > YES
> > > > Header <linux/pkt_cls.h> has symbol "TCA_FLOWER_KEY_IP_PROTO": YES
> > > > Header <linux/pkt_cls.h> has symbol "TCA_FLOWER_KEY_IPV4_SRC": YES
> > > > Header <linux/pkt_cls.h> has symbol "TCA_FLOWER_KEY_IPV4_SRC_MASK":
> > > > YES
> > > > Header <linux/pkt_cls.h> has symbol "TCA_FLOWER_KEY_IPV4_DST": YES
> > > > Header <linux/pkt_cls.h> has symbol "TCA_FLOWER_KEY_IPV4_DST_MASK":
> > > > YES
> > > > Header <linux/pkt_cls.h> has symbol "TCA_FLOWER_KEY_IPV6_SRC": YES
> > > > Header <linux/pkt_cls.h> has symbol "TCA_FLOWER_KEY_IPV6_SRC_MASK":
> > > > YES
> > > > Header <linux/pkt_cls.h> has symbol "TCA_FLOWER_KEY_IPV6_DST": YES
> > > > Header <linux/pkt_cls.h> has symbol "TCA_FLOWER_KEY_IPV6_DST_MASK":
> > > > YES
> > > > Header <linux/pkt_cls.h> has symbol "TCA_FLOWER_KEY_TCP_SRC": YES
> > > > Header <linux/pkt_cls.h> has symbol "TCA_FLOWER_KEY_TCP_SRC_MASK":
> > > > YES
> > > > Header <linux/pkt_cls.h> has symbol "TCA_FLOWER_KEY_TCP_DST": YES
> > > > Header <linux/pkt_cls.h> has symbol "TCA_FLOWER_KEY_TCP_DST_MASK":
> > > > YES
> > > > Header <linux/pkt_cls.h> has symbol "TCA_FLOWER_KEY_UDP_SRC": YES
> > > > Header <linux/pkt_cls.h> has symbol "TCA_FLOWER_KEY_UDP_SRC_MASK":
> > > > YES
> > > > Header <linux/pkt_cls.h> has symbol "TCA_FLOWER_KEY_UDP_DST": YES
> > > > Header <linux/pkt_cls.h> has symbol "TCA_FLOWER_KEY_UDP_DST_MASK":
> > > > YES
> > > > Header <linux/pkt_cls.h> has symbol "TCA_FLOWER_KEY_VLAN_ID": YES
> > > > Header <linux/pkt_cls.h> has symbol "TCA_FLOWER_KEY_VLAN_PRIO": YES
> > > > Header <linux/pkt_cls.h> has symbol "TCA_FLOWER_KEY_VLAN_ETH_TYPE":
> > > > YES
> > > > Header <linux/pkt_cls.h> has symbol "TCA_FLOWER_KEY_TCP_FLAGS": YES
> > > > Header <linux/pkt_cls.h> has symbol
> > > > "TCA_FLOWER_KEY_TCP_FLAGS_MASK": YES
> > > > Header <linux/pkt_cls.h> has symbol "TC_ACT_GOTO_CHAIN": YES
> > > > Header <linux/tc_act/tc_vlan.h> has symbol
> > > > "TCA_VLAN_PUSH_VLAN_PRIORITY":
> > > > YES
> > > > Header <linux/pkt_cls.h> has symbol "TCA_FLOWER_KEY_ENC_KEY_ID":
> > > > YES
> > > > Header <linux/pkt_cls.h> has symbol "TCA_FLOWER_KEY_ENC_IPV4_SRC":
> > > > YES
> > > > Header <linux/pkt_cls.h> has symbol
> > > > "TCA_FLOWER_KEY_ENC_IPV4_SRC_MASK":
> > > > YES
> > > > Header <linux/pkt_cls.h> has symbol "TCA_FLOWER_KEY_ENC_IPV4_DST":
> > > > YES
> > > > Header <linux/pkt_cls.h> has symbol
> > > > "TCA_FLOWER_KEY_ENC_IPV4_DST_MASK":
> > > > YES
> > > > Header <linux/pkt_cls.h> has symbol "TCA_FLOWER_KEY_ENC_IPV6_SRC":
> > > > YES
> > > > Header <linux/pkt_cls.h> has symbol
> > > > "TCA_FLOWER_KEY_ENC_IPV6_SRC_MASK":
> > > > YES
> > > > Header <linux/pkt_cls.h> has symbol "TCA_FLOWER_KEY_ENC_IPV6_DST":
> > > > YES
> > > > Header <linux/pkt_cls.h> has symbol
> > > > "TCA_FLOWER_KEY_ENC_IPV6_DST_MASK":
> > > > YES
> > > > Header <linux/pkt_cls.h> has symbol
> > > > "TCA_FLOWER_KEY_ENC_UDP_SRC_PORT": YES
> > > > Header <linux/pkt_cls.h> has symbol
> > > > "TCA_FLOWER_KEY_ENC_UDP_SRC_PORT_MASK": YES
> > > > Header <linux/pkt_cls.h> has symbol
> > > > "TCA_FLOWER_KEY_ENC_UDP_DST_PORT": YES
> > > > Header <linux/pkt_cls.h> has symbol
> > > > "TCA_FLOWER_KEY_ENC_UDP_DST_PORT_MASK": YES
> > > > Header <linux/tc_act/tc_tunnel_key.h> has symbol
> > > > "TCA_ACT_TUNNEL_KEY": YES
> > > > Header <linux/tc_act/tc_tunnel_key.h> has symbol
> > > > "TCA_TUNNEL_KEY_ENC_DST_PORT": YES
> > > > Header <linux/tc_act/tc_tunnel_key.h> has symbol
> > > > "TCA_TUNNEL_KEY_NO_CSUM":
> > > > YES
> > > > Header <linux/tc_act/tc_pedit.h> has symbol
> > > > "TCA_PEDIT_KEY_EX_HDR_TYPE_UDP": YES
> > > > Header <rdma/rdma_netlink.h> has symbol "RDMA_NL_NLDEV": YES
> > > > Header <rdma/rdma_netlink.h> has symbol "RDMA_NLDEV_CMD_GET": YES
> > > > Header <rdma/rdma_netlink.h> has symbol "RDMA_NLDEV_CMD_PORT_GET":
> > > > YES
> > > > Header <rdma/rdma_netlink.h> has symbol
> > > > "RDMA_NLDEV_ATTR_DEV_INDEX": YES
> > > > Header <rdma/rdma_netlink.h> has symbol "RDMA_NLDEV_ATTR_DEV_NAME":
> > > > YES
> > > > Header <rdma/rdma_netlink.h> has symbol
> > > > "RDMA_NLDEV_ATTR_PORT_INDEX": YES
> > > > Header <rdma/rdma_netlink.h> has symbol
> > > > "RDMA_NLDEV_ATTR_NDEV_INDEX": NO
> > > > Checking whether type "struct mlx5dv_sw_parsing_caps" has member
> > > > "sw_parsing_offloads": YES
> > > > Checking whether type "struct ibv_counter_set_init_attr" has member
> > > > "counter_set_id": YES
> > > > Checking whether type "struct ibv_counters_init_attr" has member
> > > > "comp_mask": NO
> > > > Configuring mlx5_autoconf.h using configuration
> > > > Library libmusdk found: NO
> > > > Library libmusdk found: NO
> > > > Library pcap found: NO
> > > > Compiler for C supports argument -Wno-unused-parameter: YES
> > > > Compiler for C supports argument -Wno-sign-compare: YES
> > > > Compiler for C supports argument -Wno-missing-prototypes: YES
> > > > Compiler for C supports argument -Wno-cast-qual: YES
> > > > Compiler for C supports argument -Wno-unused-function: YES
> > > > Compiler for C supports argument -Wno-unused-variable: YES
> > > > Compiler for C supports argument -Wno-strict-aliasing: YES
> > > > Compiler for C supports argument -Wno-missing-prototypes: YES
> > > > Compiler for C supports argument -Wno-unused-value: YES
> > > > Compiler for C supports argument -Wno-format-nonliteral: YES
> > > > Compiler for C supports argument -Wno-shift-negative-value: YES
> > > > Compiler for C supports argument -Wno-unused-but-set-variable: YES
> > > > Compiler for C supports argument -Wno-missing-declarations: YES
> > > > Compiler for C supports argument -Wno-maybe-uninitialized: YES
> > > > Compiler for C supports argument -Wno-strict-prototypes: YES
> > > > Compiler for C supports argument -Wno-shift-negative-value: YES
> > > > Compiler for C supports argument -Wno-implicit-fallthrough: YES
> > > > Compiler for C supports argument -Wno-format-extra-args: YES
> > > > Compiler for C supports argument -Wno-visibility: YES
> > > > Compiler for C supports argument -Wno-empty-body: YES
> > > > Compiler for C supports argument -Wno-invalid-source-encoding: YES
> > > > Compiler for C supports argument -Wno-sometimes-uninitialized: YES
> > > > Compiler for C supports argument -Wno-pointer-bool-conversion: YES
> > > > Checking for size of "void *": 8
> > > > Compiler for C supports argument -Wno-strict-aliasing: YES
> > > > Compiler for C supports argument -Wextra: YES
> > > > Compiler for C supports argument -Wdisabled-optimization: YES
> > > > Compiler for C supports argument -Waggregate-return: YES
> > > > Compiler for C supports argument -Wnested-externs: YES
> > > > Compiler for C supports argument -Wbad-function-cast: YES
> > > > Compiler for C supports argument -Wno-sign-compare: YES
> > > > Compiler for C supports argument -Wno-unused-parameter: YES
> > > > Compiler for C supports argument -Wno-unused-variable: YES
> > > > Compiler for C supports argument -Wno-empty-body: YES
> > > > Compiler for C supports argument -Wno-unused-but-set-variable: YES
> > > > Library sze2 found: NO
> > > > Header <linux/pkt_cls.h> has symbol "TCA_FLOWER_UNSPEC": YES
> > > > Header <linux/pkt_cls.h> has symbol "TCA_FLOWER_KEY_VLAN_PRIO": YES
> > > > Header <linux/pkt_cls.h> has symbol "TCA_BPF_UNSPEC": YES
> > > > Header <linux/pkt_cls.h> has symbol "TCA_BPF_FD": YES
> > > > Header <linux/tc_act/tc_bpf.h> has symbol "TCA_ACT_BPF_UNSPEC": YES
> > > > Header <linux/tc_act/tc_bpf.h> has symbol "TCA_ACT_BPF_FD": YES
> > > > Configuring tap_autoconf.h using configuration
> > > > Compiler for C supports argument -fno-prefetch-loop-arrays: YES
> > > > Compiler for C supports argument -Wno-maybe-uninitialized: YES
> > > > Compiler for C supports argument -Wall: YES
> > > > Compiler for C supports argument -Wextra: YES
> > > > Compiler for C supports argument -D_BSD_SOURCE: YES
> > > > Compiler for C supports argument -D_DEFAULT_SOURCE: YES
> > > > Compiler for C supports argument -D_XOPEN_SOURCE=600: YES
> > > > Compiler for C supports argument -Wno-unused-parameter: YES
> > > > Compiler for C supports argument -Wno-unused-value: YES
> > > > Compiler for C supports argument -Wno-strict-aliasing: YES
> > > > Compiler for C supports argument -Wno-format-extra-args: YES
> > > > Library IPSec_MB found: NO
> > > > Library IPSec_MB found: NO
> > > > Found pkg-config: /usr/bin/pkg-config (0.29.1)
> > > > Native dependency libcrypto found: YES 1.1.0g
> > > > Library libsso_kasumi found: NO
> > > > Library libmusdk found: NO
> > > > Dependency libcrypto found: YES (cached)
> > > > Dependency libcrypto found: YES (cached)
> > > > Library libsso_zuc found: NO
> > > > Dependency libisal found: NO
> > > > Dependency zlib found: NO
> > > > Compiler for C supports argument -Wno-sign-compare: YES
> > > > Compiler for C supports argument -Wno-unused-value: YES
> > > > Compiler for C supports argument -Wno-format: YES
> > > > Compiler for C supports argument -Wno-error=format-security: YES
> > > > Compiler for C supports argument -Wno-strict-aliasing: YES
> > > > Compiler for C supports argument -Wno-unused-but-set-variable: YES
> > > > Library execinfo found: NO
> > > > Compiler for C supports argument -Wno-format-truncation: YES
> > > > Dependency zlib found: NO
> > > > Library execinfo found: NO
> > > > Program doxygen found: NO
> > > > Program sphinx-build found: NO
> > > > kernel/linux/kni/meson.build:16: WARNING: Passed invalid keyword
> > > > argument
> > > > "console".
> > > > WARNING: This will become a hard error in the future.
> > > > WARNING: Unknown keyword arguments in target rte_kni: console
> > > > Configuring rte_build_config.h using configuration
> > > > Program buildtools/symlink-drivers-solibs.sh found: YES (/bin/sh
> > > > /home/cburdick/dpdk/buildtools/symlink-drivers-solibs.sh)
> > > > Message:
> > > > =================
> > > > Libraries Enabled
> > > > =================
> > > > 
> > > > libs:
> > > > \tcompat, cmdline, kvargs, eal, ring, mempool, mbuf, net,
> > > > \tethdev, pci, metrics, hash, timer, acl, bbdev, bitratestats,
> > > > \tcfgfile, compressdev, cryptodev, distributor, efd, eventdev, gro,
> > > > gso,
> > > > \tip_frag, jobstats, kni, latencystats, lpm, member, meter, power,
> > > > \tpdump, rawdev, reorder, sched, security, vhost, port, table,
> > > > \tpipeline, flow_classify, bpf,
> > > > 
> > > > Build targets in project: 411
> > > > Found ninja-1.8.2 at /usr/bin/ninja
> > > > [cburdick@dev01 ~/dpdk] (master)
> > > > $ cd build
> > > > [cburdick@dev01 ~/dpdk/build] (master)
> > > > $ ninja
> > > > [1428/1431] Generating igb_uio with a custom command.
> > > > make: Entering directory '/usr/src/linux-headers-4.15.0-20-generic'
> > > > Makefile:976: "Cannot use CONFIG_STACK_VALIDATION=y, please install
> > > > libelf-dev, libelf-devel or elfutils-libelf-devel"
> > > >   CC [M]  /home/cburdick/dpdk/build/kernel/linux/igb_uio/igb_uio.o
> > > >   Building modules, stage 2.
> > > >   MODPOST 1 modules
> > > >  
> > > > CC      /home/cburdick/dpdk/build/kernel/linux/igb_uio/igb_uio.mod.
> > > > o
> > > >   LD [M]  /home/cburdick/dpdk/build/kernel/linux/igb_uio/igb_uio.ko
> > > > make: Leaving directory '/usr/src/linux-headers-4.15.0-20-generic'
> > > > [1431/1431] Generating rte_kni with a custom command.
> > > > make: Entering directory '/usr/src/linux-headers-4.15.0-20-generic'
> > > > Makefile:976: "Cannot use CONFIG_STACK_VALIDATION=y, please install
> > > > libelf-dev, libelf-devel or elfutils-libelf-devel"
> > > >   CC [M]  /home/cburdick/dpdk/build/kernel/linux/kni/kni_net.o
> > > >   CC [M]  /home/cburdick/dpdk/build/kernel/linux/kni/kni_misc.o
> > > >   CC [M]  /home/cburdick/dpdk/build/kernel/linux/kni/kni_ethtool.o
> > > >   CC [M]
> > > > /home/cburdick/dpdk/build/kernel/linux/kni/ethtool/ixgbe/ixgbe_etht
> > > > ool.o
> > > >   CC [M]
> > > > /home/cburdick/dpdk/build/kernel/linux/kni/ethtool/ixgbe/ixgbe_8259
> > > > 9.o
> > > >   CC [M]
> > > > /home/cburdick/dpdk/build/kernel/linux/kni/ethtool/ixgbe/ixgbe_api.
> > > > o
> > > >   CC [M]
> > > > /home/cburdick/dpdk/build/kernel/linux/kni/ethtool/ixgbe/ixgbe_x540
> > > > .o
> > > >   CC [M]
> > > > /home/cburdick/dpdk/build/kernel/linux/kni/ethtool/ixgbe/ixgbe_comm
> > > > on.o
> > > >   CC [M]
> > > > /home/cburdick/dpdk/build/kernel/linux/kni/ethtool/ixgbe/ixgbe_phy.
> > > > o
> > > >   CC [M]
> > > > /home/cburdick/dpdk/build/kernel/linux/kni/ethtool/ixgbe/ixgbe_8259
> > > > 8.o
> > > >   CC [M]
> > > > /home/cburdick/dpdk/build/kernel/linux/kni/ethtool/ixgbe/ixgbe_main
> > > > .o
> > > >   CC [M]
> > > > /home/cburdick/dpdk/build/kernel/linux/kni/ethtool/ixgbe/kcompat.o
> > > >   CC [M]
> > > > /home/cburdick/dpdk/build/kernel/linux/kni/ethtool/igb/e1000_82575.
> > > > o
> > > >   CC [M]
> > > > /home/cburdick/dpdk/build/kernel/linux/kni/ethtool/igb/e1000_i210.o
> > > >   CC [M]
> > > > /home/cburdick/dpdk/build/kernel/linux/kni/ethtool/igb/e1000_mbx.o
> > > >   CC [M]
> > > > /home/cburdick/dpdk/build/kernel/linux/kni/ethtool/igb/e1000_api.o
> > > >   CC [M]
> > > > /home/cburdick/dpdk/build/kernel/linux/kni/ethtool/igb/igb_main.o
> > > >   CC [M]
> > > > /home/cburdick/dpdk/build/kernel/linux/kni/ethtool/igb/igb_vmdq.o
> > > >   CC [M]
> > > > /home/cburdick/dpdk/build/kernel/linux/kni/ethtool/igb/e1000_manage
> > > > .o
> > > >   CC [M]
> > > > /home/cburdick/dpdk/build/kernel/linux/kni/ethtool/igb/igb_ethtool.
> > > > o
> > > >   CC [M]
> > > > /home/cburdick/dpdk/build/kernel/linux/kni/ethtool/igb/igb_param.o
> > > >   CC [M]
> > > > /home/cburdick/dpdk/build/kernel/linux/kni/ethtool/igb/e1000_mac.o
> > > >   CC [M]
> > > > /home/cburdick/dpdk/build/kernel/linux/kni/ethtool/igb/e1000_phy.o
> > > >   CC [M]
> > > > /home/cburdick/dpdk/build/kernel/linux/kni/ethtool/igb/e1000_nvm.o
> > > >   LD [M]  /home/cburdick/dpdk/build/kernel/linux/kni/rte_kni.o
> > > >   Building modules, stage 2.
> > > >   MODPOST 1 modules
> > > >   CC      /home/cburdick/dpdk/build/kernel/linux/kni/rte_kni.mod.o
> > > >   LD [M]  /home/cburdick/dpdk/build/kernel/linux/kni/rte_kni.ko
> > > > make: Leaving directory '/usr/src/linux-headers-4.15.0-20-generic'
> > > > [cburdick@dev01 ~/dpdk/build] (master)
> > > > $ PKG_CONFIG_PATH=meson-private/ pkg-config --libs --static
> > > > libdpdk|grep
> > > > mlx
> > > > -L/usr/local/lib/x86_64-linux-gnu -lrte_flow_classify
> > > > -lrte_eventdev -
> > > > lrte_ip_frag -lrte_power -lrte_hash -lrte_pdump -lrte_pipeline
> > > > -lrte_table
> > > > -lrte_mbuf -lrte_bbdev -lrte_bpf -lrte_vhost -lrte_metrics
> > > > -lrte_mempool -
> > > > lrte_jobstats -lrte_reorder -lrte_net -lrte_security -lrte_eal
> > > > -lrte_ring
> > > > -lrte_ethdev -lrte_compressdev -lrte_rawdev -lrte_kvargs -lrte_pci
> > > > -
> > > > lrte_cfgfile -lrte_gro -lrte_gso -lrte_cryptodev -lrte_latencystats
> > > > -
> > > > lrte_sched -lrte_efd -lrte_distributor -lrte_acl -lrte_member -
> > > > lrte_cmdline -lrte_lpm -lrte_meter -lrte_kni -lrte_bitratestats -
> > > > lrte_timer -lrte_port -lrte_mempool_bucket -lrte_pmd_vdev_netvsc -
> > > > lrte_pmd_ark -lrte_pmd_failsafe -lrte_pmd_netvsc
> > > > -lrte_pmd_null_crypto -
> > > > lrte_bus_ifpga -lrte_common_dpaax -lrte_pmd_ixgbe
> > > > -lrte_mempool_ring -
> > > > lrte_pmd_kni -lrte_pmd_vmxnet3 -lrte_pmd_mlx4 -lrte_pmd_virtio
> > > > -Wl,--no-
> > > > as-needed -lrte_mempool_dpaa -lrte_pmd_ena -lrte_bus_fslmc
> > > > -lrte_pmd_avf -
> > > > lrte_pmd_dpaa2_sec -lrte_common_octeontx -lrte_pmd_skeleton_rawdev
> > > > -
> > > > lrte_pmd_crypto_scheduler -lrte_pmd_dpaa2_qdma -lrte_pmd_vhost -ldl
> > > > -
> > > > lrte_bus_dpaa -lrte_pmd_fm10k -lrte_pmd_bnxt -lrte_pmd_qat
> > > > -lrte_pmd_bond
> > > > -lrte_pmd_axgbe -lrte_pmd_dpaa2 -lrte_pmd_skeleton_event -
> > > > lrte_pmd_dpaa_event -lrte_mempool_stack -pthread -lrte_pmd_ccp -
> > > > lrte_pmd_octeontx_compress -lrte_pmd_sw_event
> > > > -lrte_mempool_octeontx -Wl,-
> > > > Bdynamic -lrte_pmd_dpaa_sec -lrte_pmd_atlantic
> > > > -lrte_pmd_octeontx_event -
> > > > lrte_pmd_avp -lrte_bus_pci -lrte_pmd_dpaa2_cmdif -lrte_pmd_mlx5 -
> > > > lrte_pmd_opdl_event -lrte_pmd_tap -lrte_pmd_caam_jr -lrte_pmd_sfc
> > > > -lcrypto
> > > > -lrte_pmd_enetc -lrte_mempool_dpaa2 -lrte_pmd_dpaa2_event
> > > > -lrte_pmd_ifc -
> > > > lrte_pmd_liquidio -lrte_pmd_cxgbe -lm -lrte_pmd_enic -lrte_bus_vdev
> > > > -
> > > > lrte_pmd_e1000 -lrte_pmd_softnic -lrte_pmd_ifpga_rawdev
> > > > -lrte_bus_vmbus -
> > > > lrte_pmd_octeontx_crypto -lrte_pmd_null -lnuma -lrte_common_cpt -
> > > > lrte_pmd_nfp -lrte_pmd_qede -lrte_pmd_i40e -lrte_pmd_dpaa -Wl,
> > > > --whole-
> > > > archive -lrte_pmd_bbdev_null -lrte_pmd_af_packet -lrte_pmd_thunderx
> > > > -
> > > > lrte_pmd_openssl -lrte_pmd_octeontx -lrte_pmd_dsw_event -Wl,--no-
> > > > whole-
> > > > archive -lrte_pmd_ring -lrte_pmd_virtio_crypto
> > > 
> > > That is strange. Can you try one last thing - can you update meson
> > > with "pip3 install --upgrade meson" and see if that makes any
> > > difference? [If you are using your distro's meson from /usr/bin right
> > > now, you'll probably also need to run "hash meson" afterwards too].
> > > Perhaps we have a hidden dependency on later meson versions or
> > > something like that.
> > > 
> > > /Bruce
> > 
> > We do - I can reproduce the same issue with 0.45.1, while normally I
> > run 0.47.2. Should we bump the minimum version? Or simply document it?
> > 
> Bumping the minimum version would be really nice generally for DPDK, but I
> don't think this is the point in the release cycle to do so. I need to try
> and track down why this is broken with older mesons - most version specific
> things are harmless, and I'd like to keep it that way! 
> 
> If we can't fix this in rc4, then document, I suggest. That way we don't
> require absolutely everyone to use bleeding-edge meson.
> 
> /Bruce

Hi Bruce and Luca, that seems to have fixed the problem. It appears that Meson
was warning about having a new version anyways since you're using newer features. 0.45
did not warn, but 0.48 appears to check a version->feature map:

WARNING: Project specifies a minimum meson_version '>= 0.41' but uses features which were added in newer versions:
 * 0.42.0: {'extra_cflags arg in pkgconfig.generate'}
 * 0.46.0: {'recursive arg in extract_all_objects'}
 * 0.48.0: {'console arg in custom_target'}
Found ninja-1.8.2 at /usr/bin/ninja

Thanks for resolving it!

Re: [dpdk-dev] [PATCH 1/1] eal: Don't fail secondary if primary is missing tailqs

[Bruce Richardson]

On Thu, Nov 15, 2018 at 05:36:06PM +0000, Burdick, Cliff wrote:
> 
> 
> -----Original Message-----
> From: Bruce Richardson [mailto:bruce.richardson@intel.com] 
> Sent: Thursday, November 15, 2018 9:17 AM
> To: Luca Boccassi
> Cc: Burdick, Cliff; Thomas Monjalon; Burakov, Anatoly; dev@dpdk.org
> Subject: Re: [dpdk-dev] [PATCH 1/1] eal: Don't fail secondary if primary is missing tailqs
> 
<snip>
> > Bumping the minimum version would be really nice generally for DPDK, but I
> > don't think this is the point in the release cycle to do so. I need to try
> > and track down why this is broken with older mesons - most version specific
> > things are harmless, and I'd like to keep it that way! 
> > 
> > If we can't fix this in rc4, then document, I suggest. That way we don't
> > require absolutely everyone to use bleeding-edge meson.
> > 
> > /Bruce
> 
> Hi Bruce and Luca, that seems to have fixed the problem. It appears that Meson
> was warning about having a new version anyways since you're using newer features. 0.45
> did not warn, but 0.48 appears to check a version->feature map:
> 
> WARNING: Project specifies a minimum meson_version '>= 0.41' but uses features which were added in newer versions:
>  * 0.42.0: {'extra_cflags arg in pkgconfig.generate'}
>  * 0.46.0: {'recursive arg in extract_all_objects'}
>  * 0.48.0: {'console arg in custom_target'}
> Found ninja-1.8.2 at /usr/bin/ninja
> 
> Thanks for resolving it!

Glad to hear it's fixed for you.

/Bruce

Re: [dpdk-dev] [PATCH 1/1] eal: Don't fail secondary if primary is missing tailqs

[Luca Boccassi]

On Thu, 2018-11-15 at 17:17 +0000, Bruce Richardson wrote:
> On Thu, Nov 15, 2018 at 05:05:16PM +0000, Luca Boccassi wrote:
> > On Thu, 2018-11-15 at 17:01 +0000, Richardson, Bruce wrote:
> > > > -----Original Message-----
> > > > From: Burdick, Cliff [mailto:Cliff.Burdick@viasat.com]
> > > > Sent: Thursday, November 15, 2018 4:55 PM
> > > > To: Richardson, Bruce <bruce.richardson@intel.com>
> > > > Cc: Luca Boccassi <bluca@debian.org>; Thomas Monjalon
> > > > <thomas@monjalon.net>; Burakov, Anatoly <anatoly.burakov@intel.
> > > > com>
> > > > ;
> > > > dev@dpdk.org
> > > > Subject: RE: [dpdk-dev] [PATCH 1/1] eal: Don't fail secondary
> > > > if
> > > > primary
> > > > is missing tailqs
> > > > 
> > > > 
> > > > 
> > > > -----Original Message-----
> > > > From: Bruce Richardson [mailto:bruce.richardson@intel.com]
> > > > Sent: Thursday, November 15, 2018 8:41 AM
> > > > To: Burdick, Cliff
> > > > Cc: Luca Boccassi; Thomas Monjalon; Burakov, Anatoly; dev@dpdk.
> > > > org
> > > > Subject: Re: [dpdk-dev] [PATCH 1/1] eal: Don't fail secondary
> > > > if
> > > > primary
> > > > is missing tailqs
> > > > 
> > > > > On Thu, Nov 15, 2018 at 04:15:36PM +0000, Burdick, Cliff
> > > > > wrote:
> > > > > > 
> > > > > > 
> > > > > > -----Original Message-----
> > > > > > From: Luca Boccassi [mailto:bluca@debian.org]
> > > > > > Sent: Thursday, November 15, 2018 1:33 AM
> > > > > > To: Burdick, Cliff; Bruce Richardson
> > > > > > Cc: Thomas Monjalon; Burakov, Anatoly; dev@dpdk.org
> > > > > > Subject: Re: [dpdk-dev] [PATCH 1/1] eal: Don't fail
> > > > > > secondary
> > > > > > if
> > > > > > primary is missing tailqs
> > > > > > 
> > > > > > > On Wed, 2018-11-14 at 18:24 +0000, Burdick, Cliff wrote:
> > > > > > > > 
> > > > > > > > -----Original Message-----
> > > > > > > > From: Luca Boccassi [mailto:bluca@debian.org]
> > > > > > > > Sent: Wednesday, November 14, 2018 10:15 AM
> > > > > > > > To: Burdick, Cliff; Bruce Richardson
> > > > > > > > Cc: Thomas Monjalon; Burakov, Anatoly; dev@dpdk.org
> > > > > > > > Subject: Re: [dpdk-dev] [PATCH 1/1] eal: Don't fail
> > > > > > > > secondary if
> > > > > > > > primary is missing tailqs
> > > > > > > > 
> > > > > > > > > On Wed, 2018-11-14 at 17:40 +0000, Burdick, Cliff
> > > > > > > > > wrote:
> > > > > > > > > > 
> > > > > > > > > > -----Original Message-----
> > > > > > > > > > From: Bruce Richardson [mailto:bruce.richardson@int
> > > > > > > > > > el.c
> > > > > > > > > > om]
> > > > > > > > > > Sent: Wednesday, November 14, 2018 3:48 AM
> > > > > > > > > > To: Burdick, Cliff
> > > > > > > > > > Cc: Thomas Monjalon; Burakov, Anatoly; dev@dpdk.org
> > > > > > > > > > Subject: Re: [dpdk-dev] [PATCH 1/1] eal: Don't fail
> > > > > > > > > > secondary
> > > > > > > > > > if primary is missing tailqs
> > > > > > > > > > 
> > > > > > > > > > On Tue, Nov 13, 2018 at 11:42:51PM +0000, Burdick,
> > > > > > > > > > Cliff
> > > > 
> > > > wrote:
> > > > > > > > > > > > 
> > > > > > > > > > > > ________________________________________
> > > > > > > > > > > > From: Thomas Monjalon [thomas@monjalon.net]
> > > > > > > > > > > > Sent: Tuesday, November 13, 2018 2:18 PM
> > > > > > > > > > > > To: Burdick, Cliff
> > > > > > > > > > > > Cc: Burakov, Anatoly; dev@dpdk.org;
> > > > > > > > > > > > bruce.richardson@intel.co m
> > > > > > > > > > > > Subject: Re: [dpdk-dev] [PATCH 1/1] eal: Don't
> > > > > > > > > > > > fail
> > > > > > > > > > > > secondary if primary is missing tailqs
> > > > > > > > > > > > 
> > > > > > > > > > > > 13/11/2018 23:08, Burdick, Cliff:
> > > > > > > > > > > > > From: Thomas Monjalon [mailto:thomas@monjalon
> > > > > > > > > > > > > .net
> > > > > > > > > > > > > ]
> > > > > > > > > > > > > > 13/11/2018 17:38, Burdick, Cliff:
> > > > > > > > > > > > > > > From: Thomas Monjalon [mailto:thomas@monj
> > > > > > > > > > > > > > > alon
> > > > > > > > > > > > > > > .net]
> > > > > > > > > > > > > > > 13/11/2018 16:45, Burdick, Cliff:
> > > > > > > > > > > > > > > > From: Burakov, Anatoly
> > > > 
> > > > [mailto:anatoly.burakov@intel.
> > > > > > > > > > > > > > > > com]
> > > > > > > > > > > > > > > > > On 13-Nov-18 9:21 AM, Thomas Monjalon
> > > > > > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > > > > > 13/11/2018 00:33, Burdick, Cliff:
> > > > > > > > > > > > > > > > > > > This patch was submitted by Jean
> > > > > > > > > > > > > > > > > > > Tourrilhes
> > > > > > > > > > > > > > > > > > > over two years ago, but didn't
> > > > > > > > > > > > > > > > > > > receive any
> > > > 
> > > > responses.
> > > > > > > > > > > > > > > > > > > I hit the same issue recently
> > > > > > > > > > > > > > > > > > > when
> > > > > > > > > > > > > > > > > > > trying to
> > > > > > > > > > > > > > > > > > > use cgo
> > > > > > > > > > > > > > > > > > > (Golang) as a primary process
> > > > > > > > > > > > > > > > > > > linked
> > > > > > > > > > > > > > > > > > > to
> > > > > > > > > > > > > > > > > > > libdpdk.a against a C++
> > > > > > > > > > > > > > > > > > > application
> > > > > > > > > > > > > > > > > > > linked
> > > > > > > > > > > > > > > > > > > against the same library.> > >
> > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > The question is to know why you
> > > > > > > > > > > > > > > > > > don't
> > > > > > > > > > > > > > > > > > have the
> > > > > > > > > > > > > > > > > > same constructors in primary and
> > > > > > > > > > > > > > > > > > seconday?
> > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > I've hit similar things in the past.
> > > > > > > > > > > > > > > > > I
> > > > > > > > > > > > > > > > > believe
> > > > > > > > > > > > > > > > > it was caused by our build system
> > > > > > > > > > > > > > > > > stripping out
> > > > > > > > > > > > > > > > > unused libraries (such as
> > > > > > > > > > > > > > > > > rte_hash) from the binary and thus
> > > > > > > > > > > > > > > > > not
> > > > > > > > > > > > > > > > > calling
> > > > > > > > > > > > > > > > > the constructor in the primary, but
> > > > > > > > > > > > > > > > > doing
> > > > > > > > > > > > > > > > > so in
> > > > > > > > > > > > > > > > > the secondary (or something to that
> > > > > > > > > > > > > > > > > effect). In
> > > > > > > > > > > > > > > > > any case, this is caused by linking
> > > > > > > > > > > > > > > > > different
> > > > > > > > > > > > > > > > > number of libraries to primary and
> > > > > > > > > > > > > > > > > secondary,
> > > > > > > > > > > > > > > > > and should probably be fixed in the
> > > > > > > > > > > > > > > > > build
> > > > > > > > > > > > > > > > > system, not in the tailqs code
> > > > > > > > > > > > > > > > > (unless we
> > > > > > > > > > > > > > > > > specifically support having different
> > > > > > > > > > > > > > > > > linked
> > > > > > > > > > > > > > > > > libraries to primary and
> > > > > > > > > > > > > > > > > secondary?).> >
> > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > Right, I think the original author of
> > > > > > > > > > > > > > > > the
> > > > > > > > > > > > > > > > patch
> > > > > > > > > > > > > > > > stated the reasons in the link I
> > > > > > > > > > > > > > > > provided.
> > > > > > > > > > > > > > > > The
> > > > > > > > > > > > > > > > build system seems like the most
> > > > > > > > > > > > > > > > appropriate place
> > > > > > > > > > > > > > > > to fix it, but the patch got me going
> > > > > > > > > > > > > > > > quickly. I
> > > > > > > > > > > > > > > > think the question is whether you want
> > > > > > > > > > > > > > > > DPDK
> > > > > > > > > > > > > > > > to
> > > > > > > > > > > > > > > > support these other ways of linking.
> > > > > > > > > > > > > > > > I'm
> > > > > > > > > > > > > > > > certainly not the first to use cgo,
> > > > > > > > > > > > > > > > since
> > > > > > > > > > > > > > > > there's
> > > > > > > > > > > > > > > > a virtual switch project doing the
> > > > > > > > > > > > > > > > same:
> > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > https://urldefense.proofpoint.com/v2/ur
> > > > > > > > > > > > > > > > l?u=
> > > > > > > > > > > > > > > > https-3
> > > > > > > > > > > > > > > > A__
> > > > > > > > > > > > > > > > gith
> > > > > > > > > > > > > > > > ub.co
> > > > > > > > > > > > > > > > m_lago
> > > > > > > > > > > > > > > > pu
> > > > > > > > > > > > > > > > s_vsw&d=DwICAg&c=jcv3orpCsv7C4ly8-
> > > > > > > > > > > > > > > > ubDoUfrxF5xIGWmptxGWP5vi5w&r =m1RLQ OG
> > > > > > > > > > > > > > > > Okz9MauvVLZmiGtyWc5mA7DejbPFNE1IDj-
> > > > > > > > > > > > > > > > 4&m=hQqVCNwW7eoEzB_hLFK97i8 idS8FI qX
> > > > > > > > > > > > > > > > oPeclwsIZq7Y&s=BMoBlwkqljwWIBY3SE3pPMCf
> > > > > > > > > > > > > > > > VnOU
> > > > > > > > > > > > > > > > lDuZLrn
> > > > > > > > > > > > > > > > o4-
> > > > > > > > > > > > > > > > SojKM&e=
> > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > They don't use primary/secondary
> > > > > > > > > > > > > > > > processes,
> > > > > > > > > > > > > > > > though, so the issue is  never hit. I'm
> > > > > > > > > > > > > > > > in
> > > > > > > > > > > > > > > > a
> > > > > > > > > > > > > > > > situation where using cgo seemed like
> > > > > > > > > > > > > > > > the
> > > > > > > > > > > > > > > > easiest
> > > > > > > > > > > > > > > > path to accomplish what I'm doing since
> > > > > > > > > > > > > > > > I
> > > > > > > > > > > > > > > > needed
> > > > > > > > > > > > > > > > specialized  libraries for it that were
> > > > > > > > > > > > > > > > not
> > > > > > > > > > > > > > > > available in C/C++. At some point
> > > > > > > > > > > > > > > > I  bet
> > > > > > > > > > > > > > > > someone
> > > > > > > > > > > > > > > > would use Cython to start linking
> > > > > > > > > > > > > > > > against
> > > > > > > > > > > > > > > > DPDK as
> > > > > > > > > > > > > > > > well,  and we'd likely run into the
> > > > > > > > > > > > > > > > same
> > > > > > > > > > > > > > > > issue.> >
> > > > > > > > > > > > > > > > > > For sure, we want to support using
> > > > > > > > > > > > > > > > > > DPDK
> > > > > > > > > > > > > > > > > > with
> > > > 
> > > > cgo or cython.
> > > > > > > > > > > > > > > > But it is not clear what is the
> > > > > > > > > > > > > > > > relation
> > > > > > > > > > > > > > > > with not
> > > > > > > > > > > > > > > > having the same compilation for primary
> > > > > > > > > > > > > > > > and
> > > > 
> > > > secondary.
> > > > > > > > > > > > > > > > Please
> > > > > > > > > > > > > > > > could you elaborate?> > >
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > Hi Thomas, I think Jean explained it well
> > > > > > > > > > > > > > > here:
> > > > > > > > > > > > > > > https://urldefense.proofpoint.com/v2/url?
> > > > > > > > > > > > > > > u=ht
> > > > > > > > > > > > > > > tps-3A_
> > > > > > > > > > > > > > > _de
> > > > > > > > > > > > > > > v.dp
> > > > > > > > > > > > > > > dk.narkive.
> > > > > > > > > > > > > > > com_ZM3a7QD1_dpdk-2Ddev-2Dbug-2Dstatic-
> > > > > > > > > > > > > > > 2Dconstructor
> > > > > > > > > > > > > > > s-
> > > > > > > > > > > > > > > 2Dconsider
> > > > > > > > > > > > > > > ed-2De
> > > > > > > > > > > > > > > vil&d=DwICAg&c=jcv3orpCsv7C4ly8-
> > > > > > > > > > > > > > > ubDoUfrxF5xIGWmptxGWP5vi5w&r=m1R LQOGOk
> > > > > > > > > > > > > > > z9MauvVLZmiGtyWc5mA7DejbPFNE1IDj-
> > > > > > > > > > > > > > > 4&m=C69wDgrjDX8_oXp1M_3bnmWOOZd GqwBBG
> > > > > > > > > > > > > > > 9vzkyGDWGQ&s=YYn2N7WrzJpH1ptNrLZad0nPAQdr
> > > > > > > > > > > > > > > UyqB
> > > > > > > > > > > > > > > ckk2uFu
> > > > > > > > > > > > > > > WYP
> > > > > > > > > > > > > > > Q&e=
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > "The build system of the application does
> > > > > > > > > > > > > > > not
> > > > > > > > > > > > > > > have
> > > > > > > > > > > > > > > all the subtelties of the DPDK build
> > > > > > > > > > > > > > > system,
> > > > > > > > > > > > > > > and
> > > > > > > > > > > > > > > ends up including
> > > > > > > > > > > > > > > *all*
> > > > > > > > > > > > > > > the constructors, wether they are used or
> > > > > > > > > > > > > > > not
> > > > > > > > > > > > > > > in the
> > > > > > > > > > > > > > > code.
> > > > > > > > > > > > > > > Moreover, they are included in a
> > > > > > > > > > > > > > > different
> > > > > > > > > > > > > > > order.
> > > > > > > > > > > > > > > Actually,
> > > > > > > > > > > > > > > by default the builds include no
> > > > > > > > > > > > > > > constructors
> > > > > > > > > > > > > > > at all
> > > > > > > > > > > > > > > (which is a big fail), so the library
> > > > > > > > > > > > > > > needs
> > > > > > > > > > > > > > > to be
> > > > > > > > > > > > > > > included with --whole-archive (see Snort
> > > > > > > > > > > > > > > DPDK
> > > > > > > > > > > > > > > instructions)."
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > I will get to the bottom of my exact case
> > > > > > > > > > > > > > > to
> > > > > > > > > > > > > > > understand what's happening, but my
> > > > > > > > > > > > > > > primary
> > > > > > > > > > > > > > > application is a cgo application that I'm
> > > > > > > > > > > > > > > linking to
> > > > > > > > > > > > > > > by using almost exactly the same flags
> > > > > > > > > > > > > > > that
> > > > > > > > > > > > > > > are used
> > > > > > > > > > > > > > > in the DPDK build system to build
> > > > > > > > > > > > > > > examples.
> > > > > > > > > > > > > > > The DPDK
> > > > > > > > > > > > > > > libraries I'm linking against is a single
> > > > > > > > > > > > > > > location
> > > > > > > > > > > > > > > for both primary and secondary; in other
> > > > > > > > > > > > > > > words, I
> > > > 
> > > > don't build DPDK twice.
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > OK I understand, thanks.
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > You had alluded to a pkg-config for DPDK
> > > > > > > > > > > > > > > in
> > > > > > > > > > > > > > > the 2015
> > > > > > > > > > > > > > > thread, which cgo can use, but I don't
> > > > > > > > > > > > > > > know
> > > > > > > > > > > > > > > if that
> > > > > > > > > > > > > > > ever was implemented. Cgo can use pkg-
> > > > > > > > > > > > > > > config
> > > > > > > > > > > > > > > if it's
> > > > > > > > > > > > > > > available, otherwise the only tools are
> > > > > > > > > > > > > > > specifying
> > > > > > > > > > > > > > > LDFLAGS and CFLAGS into their build
> > > > > > > > > > > > > > > system.
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > Yes, the right answer is still pkg-config
> > > > > > > > > > > > > > :)
> > > > > > > > > > > > > > The good
> > > > > > > > > > > > > > news is that it is now implemented thanks
> > > > > > > > > > > > > > to
> > > > > > > > > > > > > > the meson
> > > > > > > > > > > > > > build
> > > > > > > > > > > > > > system:
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > https://urldefense.proofpoint.com/v2/url?u=
> > > > > > > > > > > > > > http
> > > > > > > > > > > > > > -3A__gi
> > > > > > > > > > > > > > t.d
> > > > > > > > > > > > > > pdk.
> > > > > > > > > > > > > > org_dp
> > > > > > > > > > > > > > dk_tree_doc_build-2Dsdk-2Dmeson.txt-
> > > > > > > > > > > > > > 23n182&d=DwICAg&c=jcv3orpCsv7C4
> > > > > > > > > > > > > > ly8-
> > > > > > > > > > > > > > ubDoUfrxF5xIGWmptxGWP5vi5w&r=m1RLQOGOkz9Mau
> > > > > > > > > > > > > > vVLZ
> > > > > > > > > > > > > > miGtyWc
> > > > > > > > > > > > > > 5mA
> > > > > > > > > > > > > > 7Dej
> > > > > > > > > > > > > > bP
> > > > > > > > > > > > > > FNE1IDj-
> > > > > > > > > > > > > > > 4&m=C69wDgrjDX8_oXp1M_3bnmWOOZdGqwBBG9vzk
> > > > > > > > > > > > > > > yGDW
> > > > > > > > > > > > > > > GQ&s=oC
> > > > > > > > > > > > > > > 86K
> > > > > > > > > > > > > > > D_R
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > J1T6rfzi3x5zFT1Ri13ELpKmsyFqpgDbgFg&e=
> > > > > > > > > > > > > 
> > > > > > > > > > > > > Hi Thomas, are there instructions on how to
> > > > > > > > > > > > > use
> > > > > > > > > > > > > pkg-config to build the mlx4/5 PMD? I noticed
> > > > > > > > > > > > > a
> > > > > > > > > > > > > patch
> > > > > > > > > > > > > was submitted in September to add support for
> > > > > > > > > > > > > it,
> > > > > > > > > > > > > but
> > > > > > > > > > > > > that link you provided on using meson doesn't
> > > > > > > > > > > > > say
> > > > > > > > > > > > > how to
> > > > > > > > > > > > > build specific drivers. It appears to be
> > > > > > > > > > > > > disabled
> > > > > > > > > > > > > by
> > > > 
> > > > default.
> > > > > > > > > > > > > If the dependency is found, meson will enable
> > > > > > > > > > > > > the
> > > > > > > > > > > > > PMD
> > > > > > > > > > > > > when building DPDK.
> > > > > > > > > > > > 
> > > > > > > > > > > > Do you know where exactly that is? I've been
> > > > > > > > > > > > using
> > > > > > > > > > > > mlx5
> > > > > > > > > > > > for a while on this system, and I can see that
> > > > > > > > > > > > 18.11-rc2
> > > > > > > > > > > > meson
> > > > > > > > > > > > build+ninja built the pmd, but it's not on the
> > > > > > > > > > > > --
> > > > > > > > > > > > libs
> > > > > > > > > > > > build+listing
> > > > > > > > > > > > for
> > > > > > > > > > > > pkg-config. Does it tell me what I was missing?
> > > > > > > > > > > > 
> > > > > > > > > > > 
> > > > > > > > > > > For dynamic linking of applications, the drivers
> > > > > > > > > > > are
> > > > > > > > > > > not
> > > > > > > > > > > normally linked in. Instead, they should be
> > > > > > > > > > > loaded
> > > > > > > > > > > from the
> > > > > > > > > > > drivers directory as .so files
> > > > > > > > > > > - normally by default in EAL as the driver .so's
> > > > > > > > > > > should be
> > > > > > > > > > > copied to the EAL_PMD_PATH where EAL finds them
> > > > 
> > > > automatically.
> > > > > > > > > > > [This applies to both meson and make builds,
> > > > > > > > > > > though
> > > > > > > > > > > only
> > > > > > > > > > > meson generates the .pc file for pkg-config]
> > > > > > > > > > > 
> > > > > > > > > > > If you are doing a static build, then you need to
> > > > > > > > > > > explicitly
> > > > > > > > > > > link in the drivers. You can get a list from pkg-
> > > > > > > > > > > config
> > > > > > > > > > > using the "
> > > > > > > > > > > --static" flag in this case. A good example of
> > > > > > > > > > > how to
> > > > > > > > > > > use
> > > > > > > > > > > pkg- config in this way can be found in the
> > > > > > > > > > > Makefiles
> > > > > > > > > > > for
> > > > > > > > > > > most examples, e.g. examples/helloworld/Makefile,
> > > > > > > > > > > reproduced
> > > > 
> > > > below.
> > > > > > > > > > > 
> > > > > > > > > > > Regards,
> > > > > > > > > > > /Bruce
> > > > > > > > > > > 
> > > > > > > > > > > all: shared
> > > > > > > > > > > .PHONY: shared static
> > > > > > > > > > > shared: build/$(APP)-shared
> > > > > > > > > > >         ln -sf $(APP)-shared build/$(APP)
> > > > > > > > > > > static: build/$(APP)-static
> > > > > > > > > > >         ln -sf $(APP)-static build/$(APP)
> > > > > > > > > > > 
> > > > > > > > > > > PC_FILE := $(shell pkg-config --path libdpdk)
> > > > > > > > > > > CFLAGS
> > > > > > > > > > > += -O3
> > > > > > > > > > > $(shell pkg-config --cflags libdpdk)
> > > > > > > > > > > LDFLAGS_SHARED =
> > > > > > > > > > > $(shell
> > > > > > > > > > > pkg- config -- libs libdpdk) LDFLAGS_STATIC =
> > > > > > > > > > > -Wl,-
> > > > > > > > > > > Bstatic
> > > > > > > > > > > $(shell pkg-config
> > > > > > > > > > > --
> > > > > > > > > > > static --libs libdpdk)
> > > > > > > > > > > 
> > > > > > > > > > > build/$(APP)-shared: $(SRCS-y) Makefile
> > > > > > > > > > > $(PC_FILE) |
> > > > > > > > > > > build
> > > > > > > > > > >         $(CC) $(CFLAGS) $(SRCS-y) -o $@
> > > > > > > > > > > $(LDFLAGS)
> > > > > > > > > > > $(LDFLAGS_SHARED)
> > > > > > > > > > > 
> > > > > > > > > > > build/$(APP)-static: $(SRCS-y) Makefile
> > > > > > > > > > > $(PC_FILE) |
> > > > > > > > > > > build
> > > > > > > > > > >         $(CC) $(CFLAGS) $(SRCS-y) -o $@
> > > > > > > > > > > $(LDFLAGS)
> > > > > > > > > > > $(LDFLAGS_STATIC)
> > > > > > > > > > > 
> > > > > > > > > > > build:
> > > > > > > > > > >         @mkdir -p $@
> > > > > > > > > > 
> > > > > > > > > > Thanks Bruce. I tried getting this to compile using
> > > > > > > > > > cgo, and
> > > > > > > > > > it's causing more pain than it's worth. I used the
> > > > > > > > > > --
> > > > > > > > > > static
> > > > > > > > > > --libs options, and there were still numerous
> > > > > > > > > > linker
> > > > > > > > > > errors,
> > > > > > > > > > some specific to mlx, and some not. Specifically
> > > > > > > > > > libmlx5 and
> > > > > > > > > > libmnl are both needed, but they're not part of the
> > > > > > > > > > linker
> > > > > > > > > > line from pkg-config. At this point I'll just break
> > > > > > > > > > the
> > > > > > > > > > Go
> > > > > > > > > > application up into a separate C application that
> > > > > > > > > > handles all
> > > > > > > > > > the DPDK parts, and send messages between them.
> > > > > > > > > 
> > > > > > > > > Hi,
> > > > > > > > > 
> > > > > > > > > As far as I can see, both mnl and mlx5 (and all the
> > > > > > > > > other
> > > > > > > > > reverse
> > > > > > > > > dependencies) are listed correctly in the libdpdk.pc
> > > > > > > > > Libs.private entry, and pkg-config --libs --static
> > > > > > > > > libdpdk.pc
> > > > > > > > > does print them as intended. This is with 18.11-rc3.
> > > > > > > > > Are you sure everything is correct (pkg-config path
> > > > > > > > > is
> > > > > > > > > right, --
> > > > > > > > > static is used, etc)?
> > > > > > > > > 
> > > > > > > > > --
> > > > > > > > > Kind regards,
> > > > > > > > > Luca Boccassi
> > > > > > > > 
> > > > > > > > Hi Luca, here is what pkg-config gives:
> > > > > > > > 
> > > > > > > > PKG_CONFIG_PATH=meson-private/ pkg-config --libs --
> > > > > > > > static
> > > > > > > > libdpdk
> > > > > > > > -L/usr/local/lib/x86_64-linux-gnu -lrte_eventdev
> > > > > > > > -lrte_power
> > > > > > > > -lrte_ip_frag -lrte_hash -lrte_pdump -lrte_eal
> > > > > > > > -lrte_pipeline
> > > > > > > > -lrte_table -lrte_bbdev -lrte_bpf -lrte_vhost
> > > > > > > > -lrte_metrics
> > > > > > > > -lrte_jobstats -lrte_net -lrte_reorder -lrte_ring
> > > > > > > > -lrte_mempool
> > > > > > > > -lrte_security -lrte_compressdev -lrte_rawdev
> > > > > > > > -lrte_mbuf
> > > > > > > > -lrte_kvargs -lrte_port -lrte_pci -lrte_ethdev
> > > > > > > > -lrte_gro
> > > > > > > > -lrte_gso
> > > > > > > > -lrte_cryptodev -lrte_sched -lrte_latencystats
> > > > > > > > -lrte_efd
> > > > > > > > -lrte_distributor -lrte_meter -lrte_acl -lrte_member
> > > > > > > > -lrte_cmdline
> > > > > > > > -lrte_lpm -lrte_kni -lrte_cfgfile -lrte_bitratestats
> > > > > > > > -lrte_timer
> > > > > > > > -lrte_flow_classify -lrte_mempool_bucket
> > > > > > > > -lrte_pmd_null_crypto
> > > > > > > > -lrte_pmd_failsafe -lrte_bus_ifpga -lrte_pmd_atlantic
> > > > > > > > -lrte_pmd_mlx4 -lrte_pmd_vmxnet3 -lrte_pmd_avp
> > > > > > > > -lrte_common_dpaax
> > > > > > > > -lrte_pmd_ena -lcrypto -lrte_bus_fslmc -ldl
> > > > > > > > -lrte_pmd_avf
> > > > > > > > -lrte_pmd_crypto_scheduler -lrte_pmd_netvsc
> > > > > > > > -lrte_pmd_vhost
> > > > > > > > -lrte_bus_dpaa -lrte_mempool_dpaa2
> > > > > > > > -lrte_common_octeontx
> > > > > > > > -lrte_pmd_liquidio -lrte_pmd_ifc -Wl,-Bdynamic -lnuma
> > > > > > > > -lrte_pmd_enic -lrte_common_cpt -pthread
> > > > > > > > -lrte_pmd_octeontx_crypto
> > > > > > > > -lrte_pmd_qat -lrte_bus_vmbus -lrte_pmd_null -lm
> > > > > > > > -lrte_pmd_dpaa
> > > > > > > > -lrte_bus_vdev -lrte_pmd_dpaa2 -lrte_pmd_skeleton_event
> > > > > > > > -lrte_pmd_af_packet -lrte_pmd_octeontx
> > > > > > > > -lrte_pmd_thunderx
> > > > > > > > -lrte_pmd_ring -lrte_pmd_octeontx_event
> > > > > > > > -lrte_pmd_sw_event
> > > > > > > > -lrte_pmd_ark -lrte_mempool_octeontx -lrte_pmd_ixgbe
> > > > > > > > -lrte_pmd_kni
> > > > > > > > -lrte_mempool_ring -lrte_pmd_virtio_crypto
> > > > > > > > -lrte_mempool_dpaa
> > > > > > > > -lrte_pmd_dpaa2_cmdif -lrte_bus_pci
> > > > > > > > -lrte_pmd_opdl_event
> > > > > > > > -lrte_pmd_mlx5 -lrte_pmd_virtio -lrte_pmd_tap
> > > > > > > > -lrte_pmd_caam_jr
> > > > > > > > -lrte_pmd_dpaa2_sec -lrte_pmd_dpaa2_qdma
> > > > > > > > -lrte_pmd_enetc
> > > > > > > > -lrte_pmd_sfc -lrte_pmd_bnxt -lrte_pmd_dpaa2_event
> > > > > > > > -lrte_pmd_cxgbe
> > > > > > > > -Wl,--whole-archive -Wl,--no- as-needed -lrte_pmd_e1000
> > > > > > > > -lrte_pmd_softnic -lrte_pmd_bond -lrte_pmd_fm10k
> > > > > > > > -lrte_pmd_i40e
> > > > > > > > -lrte_pmd_nfp -lrte_pmd_qede -Wl,--no- whole-archive
> > > > > > > > -lrte_pmd_axgbe -lrte_pmd_ccp -lrte_pmd_ifpga_rawdev
> > > > > > > > -lrte_pmd_bbdev_null -lrte_pmd_openssl
> > > > > > > > -lrte_pmd_dsw_event
> > > > > > > > -lrte_pmd_dpaa_event -lrte_mempool_stack
> > > > > > > > -lrte_pmd_vdev_netvsc
> > > > > > > > -lrte_pmd_dpaa_sec -lrte_pmd_skeleton_rawdev
> > > > > > > > -lrte_pmd_octeontx_compress
> > > > > > > > 
> > > > > > > > You'll notice there's no mlx5 or mnl in that list. I
> > > > > > > > was
> > > > > > > > using
> > > > > > > > 18.11-
> > > > > > > > rc2 since I cloned early yesterday. Perhaps meson
> > > > > > > > determined not
> > > > > > > > to put it in there for some reason?
> > > > > > > 
> > > > > > > Were mlx5/mnl found at meson configure time?
> > > > > > > 
> > > > > > > --
> > > > > > > Kind regards,
> > > > > > > Luca Boccassi
> > > > > > 
> > > > > > Hi Luca, yes, it was:
> > > > > > 
> > > > > > Library mnl found: YES
> > > > > > Library mlx4 found: YES
> > > > > > Library ibverbs found: YES
> > > > > > Compiler for C supports argument -Wextra: YES Compiler for
> > > > > > C
> > > > > > supports
> > > > > > argument -std=c11: YES Compiler for C supports argument
> > > > > > -Wno-strict-prototypes: YES Compiler for C supports
> > > > > > argument
> > > > > > -D_BSD_SOURCE: YES Compiler for C supports argument
> > > > > > -D_DEFAULT_SOURCE:
> > > > > > YES Compiler for C supports argument -D_XOPEN_SOURCE=600:
> > > > > > YES
> > > > > > Checking
> > > > > > whether type "struct mlx4_wqe_lso_seg" has member
> > > > > > "mss_hdr_size": YES
> > > > > > Configuring mlx4_autoconf.h using configuration Library mnl
> > > > > > found: YES
> > > > > > Library mlx5 found: YES Library ibverbs found: YES ...
> > > > > > PKG_CONFIG_PATH=meson-private/ pkg-config --libs --static
> > > > > > libdpdk
> > > > > > -L/usr/local/lib/x86_64-linux-gnu -lrte_eventdev
> > > > > > -lrte_power
> > > > > > -lrte_ip_frag -lrte_hash -lrte_pdump -lrte_eal
> > > > > > -lrte_pipeline
> > > > > > -lrte_table -lrte_bbdev -lrte_bpf -lrte_vhost -lrte_metrics
> > > > > > -lrte_jobstats -lrte_net -lrte_reorder -lrte_ring
> > > > > > -lrte_mempool
> > > > > > -lrte_security -lrte_compressdev -lrte_rawdev -lrte_mbuf
> > > > > > -lrte_kvargs
> > > > > > -lrte_port -lrte_pci -lrte_ethdev -lrte_gro -lrte_gso
> > > > > > -lrte_cryptodev
> > > > > > -lrte_sched -lrte_latencystats -lrte_efd -lrte_distributor
> > > > > > -lrte_meter
> > > > > > -lrte_acl -lrte_member -lrte_cmdline -lrte_lpm -lrte_kni
> > > > > > -lrte_cfgfile
> > > > > > -lrte_bitratestats -lrte_timer -lrte_flow_classify
> > > > > > -lrte_pmd_ccp
> > > > > > -lrte_mempool_bucket -lrte_pmd_failsafe -lrte_pmd_netvsc
> > > > > > -lrte_pmd_null_crypto -lrte_bus_ifpga -lrte_pmd_atlantic
> > > > > > -lrte_pmd_octeontx_event -lrte_pmd_avp -lrte_pmd_mlx4
> > > > > > -lrte_common_dpaax -lrte_pmd_skeleton_rawdev -lrte_pmd_ena
> > > > > > -lrte_pmd_opdl_event -lrte_bus_fslmc -lnuma -lrte_pmd_avf
> > > > > > -lrte_pmd_crypto_scheduler -lrte_pmd_vhost -lrte_bus_dpaa
> > > > > > -lrte_mempool_dpaa2 -lrte_common_octeontx -Wl,--no-as-
> > > > > > needed
> > > > > > -lcrypto
> > > > > > -lrte_pmd_ifc -lrte_pmd_liquidio -lrte_pmd_enic
> > > > > > -lrte_common_cpt
> > > > > > -Wl,--no-whole-archive -lrte_bus_vmbus
> > > > > > -lrte_pmd_octeontx_crypto
> > > > > > -lrte_pmd_qat -lrte_pmd_ifpga_rawdev -lrte_pmd_dpaa
> > > > > > -lrte_bus_vdev
> > > > > > -lrte_pmd_bbdev_null -lrte_pmd_dpaa2
> > > > > > -lrte_pmd_skeleton_event
> > > > > > -lrte_pmd_ring -lrte_pmd_af_packet -lrte_pmd_thunderx
> > > > > > -lrte_pmd_dpaa_event -lrte_pmd_octeontx_compress
> > > > > > -lrte_pmd_dpaa_sec
> > > > > > -lrte_pmd_sw_event -Wl,--whole-archive -lrte_pmd_ark
> > > > > > -lrte_mempool_octeontx -lrte_pmd_ixgbe -lrte_mempool_ring
> > > > > > -lrte_pmd_kni -lrte_pmd_vmxnet3 -lrte_mempool_dpaa
> > > > > > -lrte_bus_pci
> > > > > > -lrte_pmd_dpaa2_cmdif -lrte_pmd_mlx5 -lrte_pmd_tap
> > > > > > -lrte_pmd_caam_jr
> > > > > > -lrte_pmd_dpaa2_sec -lm -lrte_pmd_dpaa2_qdma
> > > > > > -lrte_pmd_enetc
> > > > > > -lrte_pmd_virtio -lrte_pmd_bnxt -lrte_pmd_dpaa2_event
> > > > > > -lrte_pmd_sfc
> > > > > > -lrte_pmd_cxgbe -pthread -lrte_pmd_e1000 -lrte_pmd_softnic
> > > > > > -ldl
> > > > > > -lrte_pmd_null -lrte_pmd_bond -lrte_pmd_fm10k
> > > > > > -lrte_pmd_i40e
> > > > > > -lrte_pmd_nfp -lrte_pmd_qede -lrte_pmd_axgbe -Wl,-Bdynamic
> > > > > > -lrte_pmd_openssl -lrte_pmd_octeontx -lrte_pmd_dsw_event
> > > > > > -lrte_mempool_stack -lrte_pmd_virtio_crypto
> > > > > > -lrte_pmd_vdev_netvsc
> > > > > 
> > > > > Is this with latest DPDK from git? because I see the exact
> > > > > same
> > > > > as Luca:
> > > > > 
> > > > > $ PKG_CONFIG_PATH=build/meson-private/ pkg-config --libs --
> > > > > static
> > > > 
> > > > libdpdk | grep mlx
> > > > > -L/usr/local/lib64 -lrte_telemetry -lrte_bpf
> > > > > -lrte_flow_classify
> > > > > -
> > > > 
> > > > lrte_pipeline -lrte_table -lrte_port -lrte_vhost -lrte_security
> > > > -
> > > > lrte_sched -lrte_reorder -lrte_rawdev -lrte_pdump -lrte_power
> > > > -lrte_meter
> > > > -lrte_member -lrte_lpm -lrte_latencystats -lrte_kni
> > > > -lrte_jobstats
> > > > -
> > > > lrte_ip_frag -lrte_gso -lrte_gro -lrte_eventdev -lrte_efd -
> > > > lrte_distributor -lrte_cryptodev -lrte_compressdev
> > > > -lrte_cfgfile -
> > > > lrte_bitratestats -lrte_bbdev -lrte_acl -lrte_timer -lrte_hash
> > > > -
> > > > lrte_metrics -lrte_pci -lrte_ethdev -lrte_net -lrte_mbuf
> > > > -lrte_mempool -
> > > > lrte_ring -lrte_eal -lrte_kvargs -lrte_cmdline
> > > > -L/usr/local/lib64 -
> > > > lrte_kvargs -lrte_eal -lrte_ring -lrte_mempool -lrte_mbuf
> > > > -lrte_pci
> > > > -
> > > > lrte_cryptodev -lrte_net -lrte_cmdline -lrte_ethdev -lrte_hash
> > > > -lrte_timer
> > > > -lrte_common_dpaax -lrte_eventdev -lrte_rawdev -lrte_bus_dpaa -
> > > > lrte_bus_fslmc -lrte_bus_pci -lrte_common_octeontx
> > > > -lrte_bus_vdev -
> > > > lrte_meter -lrte_sched -lrte_ip_frag -lz -lrte_mempool_dpaa -
> > > > lrte_mempool_dpaa2 -lrte_vhost -lrte_security -lrte_kni -lmnl
> > > > -lmlx4 -
> > > > libverbs -lmnl -lmlx5 -libverbs -lrte_bus_vmbus
> > > > -lrte_mempool_octeontx -
> > > > lpcap -lrte_port -lrte_lpm -lrte_acl -lrte_table -lrte_pipeline
> > > > -lsze2 -
> > > > lrte_gso -lIPSec_MB -lIPSec_MB -lrte_common_cpt -lrte_reorder -
> > > > lrte_compressdev -lrte_pmd_dpaa -lrte_pmd_dpaa2
> > > > -lrte_pmd_dpaa2_sec
> > > > -
> > > > lrte_pmd_octeontx -lrte_bbdev -lrte_bus_ifpga -Wl,--whole-
> > > > archive -
> > > > lrte_mempool_bucket -lrte_mempool_ring -lrte_mempool_stack -
> > > > lrte_pmd_af_packet -lrte_pmd_ark -lrte_pmd_atlantic
> > > > -lrte_pmd_avf -
> > > > lrte_pmd_avp -lrte_pmd_axgbe -lrte_pmd_bond -lrte_pmd_bnx2x
> > > > -lrte_pmd_bnxt
> > > > -lrte_pmd_cxgbe -lrte_pmd_e1000 -lrte_pmd_ena -lrte_pmd_enetc -
> > > > lrte_pmd_enic -lrte_pmd_failsafe -lrte_pmd_fm10k -lrte_pmd_i40e
> > > > -
> > > > lrte_pmd_ifc -lrte_pmd_ixgbe -lrte_pmd_kmod -lrte_pmd_kni -
> > > > lrte_pmd_liquidio -lrte_pmd_mlx4 -lrte_pmd_mlx5
> > > > -lrte_pmd_netvsc -
> > > > lrte_pmd_nfp -lrte_pmd_null -lrte_pmd_pcap -lrte_pmd_qede
> > > > -lrte_pmd_ring -
> > > > lrte_pmd_sfc -lrte_pmd_softnic -lrte_pmd_szedata2 -lrte_pmd_tap
> > > > -
> > > > lrte_pmd_thunderx -lrte_pmd_vdev_netvsc -lrte_pmd_vhost
> > > > -lrte_pmd_virtio -
> > > > lrte_pmd_vmxnet3 -lrte_pmd_aesni_gcm -lrte_pmd_aesni_mb
> > > > -lrte_pmd_caam_jr
> > > > -lrte_pmd_ccp -lrte_pmd_dpaa_sec -lrte_pmd_null_crypto -
> > > > lrte_pmd_octeontx_crypto -lrte_pmd_openssl
> > > > -lrte_pmd_crypto_scheduler -
> > > > lrte_pmd_virtio_crypto -lrte_pmd_octeontx_compress
> > > > -lrte_pmd_qat -
> > > > lrte_pmd_zlib -lrte_pmd_dpaa_event -lrte_pmd_dpaa2_event -
> > > > lrte_pmd_octeontx_event -lrte_pmd_opdl_event
> > > > -lrte_pmd_skeleton_event -
> > > > lrte_pmd_sw_event -lrte_pmd_dsw_event -lrte_pmd_bbdev_null -
> > > > lrte_pmd_skeleton_rawdev -lrte_pmd_dpaa2_cmdif
> > > > -lrte_pmd_dpaa2_qdma
> > > > -
> > > > lrte_pmd_ifpga_rawdev -lrte_pmd_ioat_copy -Wl,--no-whole-
> > > > archive
> > > > -Wl,-
> > > > Bdynamic -Wl,--no-as-needed -pthread -lm -ldl -lnuma -lbsd
> > > > -lpcap
> > > > -lcrypto
> > > > -lcrypto -lz -lcrypto -ldl -pthread -lz
> > > > 
> > > > Hi Bruce, I tried with rc3 and a new clone from right now, and
> > > > get
> > > > the
> > > > same results:
> > > > 
> > > > $ meson build
> > > > The Meson build system
> > > > Version: 0.45.1
> > > > Source dir: /home/cburdick/dpdk
> > > > Build dir: /home/cburdick/dpdk/build
> > > > Build type: native build
> > > > Project name: DPDK
> > > > Native C compiler: cc (gcc 7.3.0 "cc (Ubuntu 7.3.0-
> > > > 27ubuntu1~18.04)
> > > > 7.3.0")
> > > > Build machine cpu family: x86_64
> > > > Build machine cpu: x86_64
> > > > Library numa found: YES
> > > > Has header "numaif.h": YES
> > > > Library bsd found: NO
> > > > Checking for size of "void *": 8
> > > > Compiler for C supports argument -Wsign-compare: YES
> > > > Compiler for C supports argument -Wcast-qual: YES
> > > > Compiler for C supports argument -Wno-address-of-packed-member: 
> > > > YES
> > > > Fetching value of define "__SSE4_2__": 1
> > > > Fetching value of define "__AES__": 1
> > > > Fetching value of define "__PCLMUL__": 1
> > > > Fetching value of define "__AVX__": 1
> > > > Fetching value of define "__AVX2__": 1
> > > > Fetching value of define "__AVX512F__":
> > > > Compiler for C supports argument -Wno-format-truncation: YES
> > > > Checking for size of "void *": 8
> > > > Has header "linux/userfaultfd.h": YES
> > > > Checking for size of "void *": 8
> > > > Library elf found: NO
> > > > Library jansson found: NO
> > > > Program gen-pmdinfo-cfile.sh found: YES
> > > > (/home/cburdick/dpdk/buildtools/gen-pmdinfo-cfile.sh)
> > > > Compiler for C supports argument -Wno-format-truncation: YES
> > > > Library libmusdk found: NO
> > > > Compiler for C supports argument -Wno-cast-qual: YES
> > > > Compiler for C supports argument -Wno-pointer-to-int-cast: YES
> > > > Library z found: NO
> > > > Compiler for C supports argument -Wno-uninitialized: YES
> > > > Compiler for C supports argument -Wno-unused-parameter: YES
> > > > Compiler for C supports argument -Wno-unused-variable: YES
> > > > Compiler for C supports argument -Wno-misleading-indentation:
> > > > YES
> > > > Compiler for C supports argument -Wno-implicit-fallthrough: YES
> > > > Checking for size of "void *": 8
> > > > Compiler for C supports argument -Wno-unused-parameter: YES
> > > > Compiler for C supports argument -Wno-unused-value: YES
> > > > Compiler for C supports argument -Wno-strict-aliasing: YES
> > > > Compiler for C supports argument -Wno-format-extra-args: YES
> > > > Compiler for C supports argument -Wno-unused-variable: YES
> > > > Compiler for C supports argument -Wno-missing-field-
> > > > initializers:
> > > > YES
> > > > Compiler for C supports argument -Wno-sign-compare: YES
> > > > Compiler for C supports argument -Wno-unused-value: YES
> > > > Compiler for C supports argument -Wno-format: YES
> > > > Compiler for C supports argument -Wno-error=format-security:
> > > > YES
> > > > Compiler for C supports argument -Wno-strict-aliasing: YES
> > > > Compiler for C supports argument -Wno-unused-but-set-variable:
> > > > YES
> > > > Compiler for C supports argument -Wno-unused-value: YES
> > > > Compiler for C supports argument -Wno-unused-but-set-variable:
> > > > YES
> > > > Library mnl found: YES
> > > > Library mlx4 found: YES
> > > > Library ibverbs found: YES
> > > > Compiler for C supports argument -Wextra: YES
> > > > Compiler for C supports argument -std=c11: YES
> > > > Compiler for C supports argument -Wno-strict-prototypes: YES
> > > > Compiler for C supports argument -D_BSD_SOURCE: YES
> > > > Compiler for C supports argument -D_DEFAULT_SOURCE: YES
> > > > Compiler for C supports argument -D_XOPEN_SOURCE=600: YES
> > > > Checking whether type "struct mlx4_wqe_lso_seg" has member
> > > > "mss_hdr_size":
> > > > YES
> > > > Configuring mlx4_autoconf.h using configuration
> > > > Library mnl found: YES
> > > > Library mlx5 found: YES
> > > > Library ibverbs found: YES
> > > > Compiler for C supports argument -Wextra: YES
> > > > Compiler for C supports argument -std=c11: YES
> > > > Compiler for C supports argument -Wno-strict-prototypes: YES
> > > > Compiler for C supports argument -D_BSD_SOURCE: YES
> > > > Compiler for C supports argument -D_DEFAULT_SOURCE: YES
> > > > Compiler for C supports argument -D_XOPEN_SOURCE=600: YES
> > > > Header <infiniband/mlx5dv.h> has symbol
> > > > "MLX5DV_CQE_RES_FORMAT_CSUM_STRIDX": YES
> > > > Header <infiniband/mlx5dv.h> has symbol
> > > > "MLX5DV_CONTEXT_MASK_TUNNEL_OFFLOADS": YES
> > > > Header <infiniband/mlx5dv.h> has symbol
> > > > "MLX5DV_CONTEXT_FLAGS_MPW_ALLOWED": YES
> > > > Header <infiniband/mlx5dv.h> has symbol
> > > > "MLX5DV_CONTEXT_FLAGS_CQE_128B_COMP": YES
> > > > Header <infiniband/mlx5dv.h> has symbol
> > > > "MLX5DV_CQ_INIT_ATTR_FLAGS_CQE_PAD": YES
> > > > Header <infiniband/mlx5dv.h> has symbol
> > > > "mlx5dv_create_flow_action_packet_reformat": NO
> > > > Header <infiniband/verbs.h> has symbol "IBV_FLOW_SPEC_MPLS":
> > > > YES
> > > > Header <infiniband/verbs.h> has symbol
> > > > "IBV_WQ_FLAG_RX_END_PADDING": NO
> > > > Header <linux/ethtool.h> has symbol
> > > > "SUPPORTED_40000baseKR4_Full":
> > > > YES
> > > > Header <linux/ethtool.h> has symbol
> > > > "SUPPORTED_40000baseCR4_Full":
> > > > YES
> > > > Header <linux/ethtool.h> has symbol
> > > > "SUPPORTED_40000baseSR4_Full":
> > > > YES
> > > > Header <linux/ethtool.h> has symbol
> > > > "SUPPORTED_40000baseLR4_Full":
> > > > YES
> > > > Header <linux/ethtool.h> has symbol
> > > > "SUPPORTED_56000baseKR4_Full":
> > > > YES
> > > > Header <linux/ethtool.h> has symbol
> > > > "SUPPORTED_56000baseCR4_Full":
> > > > YES
> > > > Header <linux/ethtool.h> has symbol
> > > > "SUPPORTED_56000baseSR4_Full":
> > > > YES
> > > > Header <linux/ethtool.h> has symbol
> > > > "SUPPORTED_56000baseLR4_Full":
> > > > YES
> > > > Header <linux/ethtool.h> has symbol
> > > > "ETHTOOL_LINK_MODE_25000baseCR_Full_BIT": YES
> > > > Header <linux/ethtool.h> has symbol
> > > > "ETHTOOL_LINK_MODE_50000baseCR2_Full_BIT": YES
> > > > Header <linux/ethtool.h> has symbol
> > > > "ETHTOOL_LINK_MODE_100000baseKR4_Full_BIT": YES
> > > > Header <linux/if_link.h> has symbol "IFLA_PHYS_SWITCH_ID": YES
> > > > Header <linux/if_link.h> has symbol "IFLA_PHYS_PORT_NAME": YES
> > > > Header <linux/if_link.h> has symbol
> > > > "IFLA_VXLAN_COLLECT_METADATA":
> > > > YES
> > > > Header <linux/rtnetlink.h> has symbol "TCA_CHAIN": YES
> > > > Header <linux/pkt_cls.h> has symbol "TCA_FLOWER_ACT": YES
> > > > Header <linux/pkt_cls.h> has symbol "TCA_FLOWER_FLAGS": YES
> > > > Header <linux/pkt_cls.h> has symbol "TCA_FLOWER_KEY_ETH_TYPE":
> > > > YES
> > > > Header <linux/pkt_cls.h> has symbol "TCA_FLOWER_KEY_ETH_DST":
> > > > YES
> > > > Header <linux/pkt_cls.h> has symbol
> > > > "TCA_FLOWER_KEY_ETH_DST_MASK":
> > > > YES
> > > > Header <linux/pkt_cls.h> has symbol "TCA_FLOWER_KEY_ETH_SRC":
> > > > YES
> > > > Header <linux/pkt_cls.h> has symbol
> > > > "TCA_FLOWER_KEY_ETH_SRC_MASK":
> > > > YES
> > > > Header <linux/pkt_cls.h> has symbol "TCA_FLOWER_KEY_IP_PROTO":
> > > > YES
> > > > Header <linux/pkt_cls.h> has symbol "TCA_FLOWER_KEY_IPV4_SRC":
> > > > YES
> > > > Header <linux/pkt_cls.h> has symbol
> > > > "TCA_FLOWER_KEY_IPV4_SRC_MASK":
> > > > YES
> > > > Header <linux/pkt_cls.h> has symbol "TCA_FLOWER_KEY_IPV4_DST":
> > > > YES
> > > > Header <linux/pkt_cls.h> has symbol
> > > > "TCA_FLOWER_KEY_IPV4_DST_MASK":
> > > > YES
> > > > Header <linux/pkt_cls.h> has symbol "TCA_FLOWER_KEY_IPV6_SRC":
> > > > YES
> > > > Header <linux/pkt_cls.h> has symbol
> > > > "TCA_FLOWER_KEY_IPV6_SRC_MASK":
> > > > YES
> > > > Header <linux/pkt_cls.h> has symbol "TCA_FLOWER_KEY_IPV6_DST":
> > > > YES
> > > > Header <linux/pkt_cls.h> has symbol
> > > > "TCA_FLOWER_KEY_IPV6_DST_MASK":
> > > > YES
> > > > Header <linux/pkt_cls.h> has symbol "TCA_FLOWER_KEY_TCP_SRC":
> > > > YES
> > > > Header <linux/pkt_cls.h> has symbol
> > > > "TCA_FLOWER_KEY_TCP_SRC_MASK":
> > > > YES
> > > > Header <linux/pkt_cls.h> has symbol "TCA_FLOWER_KEY_TCP_DST":
> > > > YES
> > > > Header <linux/pkt_cls.h> has symbol
> > > > "TCA_FLOWER_KEY_TCP_DST_MASK":
> > > > YES
> > > > Header <linux/pkt_cls.h> has symbol "TCA_FLOWER_KEY_UDP_SRC":
> > > > YES
> > > > Header <linux/pkt_cls.h> has symbol
> > > > "TCA_FLOWER_KEY_UDP_SRC_MASK":
> > > > YES
> > > > Header <linux/pkt_cls.h> has symbol "TCA_FLOWER_KEY_UDP_DST":
> > > > YES
> > > > Header <linux/pkt_cls.h> has symbol
> > > > "TCA_FLOWER_KEY_UDP_DST_MASK":
> > > > YES
> > > > Header <linux/pkt_cls.h> has symbol "TCA_FLOWER_KEY_VLAN_ID":
> > > > YES
> > > > Header <linux/pkt_cls.h> has symbol "TCA_FLOWER_KEY_VLAN_PRIO":
> > > > YES
> > > > Header <linux/pkt_cls.h> has symbol
> > > > "TCA_FLOWER_KEY_VLAN_ETH_TYPE":
> > > > YES
> > > > Header <linux/pkt_cls.h> has symbol "TCA_FLOWER_KEY_TCP_FLAGS":
> > > > YES
> > > > Header <linux/pkt_cls.h> has symbol
> > > > "TCA_FLOWER_KEY_TCP_FLAGS_MASK": YES
> > > > Header <linux/pkt_cls.h> has symbol "TC_ACT_GOTO_CHAIN": YES
> > > > Header <linux/tc_act/tc_vlan.h> has symbol
> > > > "TCA_VLAN_PUSH_VLAN_PRIORITY":
> > > > YES
> > > > Header <linux/pkt_cls.h> has symbol
> > > > "TCA_FLOWER_KEY_ENC_KEY_ID":
> > > > YES
> > > > Header <linux/pkt_cls.h> has symbol
> > > > "TCA_FLOWER_KEY_ENC_IPV4_SRC":
> > > > YES
> > > > Header <linux/pkt_cls.h> has symbol
> > > > "TCA_FLOWER_KEY_ENC_IPV4_SRC_MASK":
> > > > YES
> > > > Header <linux/pkt_cls.h> has symbol
> > > > "TCA_FLOWER_KEY_ENC_IPV4_DST":
> > > > YES
> > > > Header <linux/pkt_cls.h> has symbol
> > > > "TCA_FLOWER_KEY_ENC_IPV4_DST_MASK":
> > > > YES
> > > > Header <linux/pkt_cls.h> has symbol
> > > > "TCA_FLOWER_KEY_ENC_IPV6_SRC":
> > > > YES
> > > > Header <linux/pkt_cls.h> has symbol
> > > > "TCA_FLOWER_KEY_ENC_IPV6_SRC_MASK":
> > > > YES
> > > > Header <linux/pkt_cls.h> has symbol
> > > > "TCA_FLOWER_KEY_ENC_IPV6_DST":
> > > > YES
> > > > Header <linux/pkt_cls.h> has symbol
> > > > "TCA_FLOWER_KEY_ENC_IPV6_DST_MASK":
> > > > YES
> > > > Header <linux/pkt_cls.h> has symbol
> > > > "TCA_FLOWER_KEY_ENC_UDP_SRC_PORT": YES
> > > > Header <linux/pkt_cls.h> has symbol
> > > > "TCA_FLOWER_KEY_ENC_UDP_SRC_PORT_MASK": YES
> > > > Header <linux/pkt_cls.h> has symbol
> > > > "TCA_FLOWER_KEY_ENC_UDP_DST_PORT": YES
> > > > Header <linux/pkt_cls.h> has symbol
> > > > "TCA_FLOWER_KEY_ENC_UDP_DST_PORT_MASK": YES
> > > > Header <linux/tc_act/tc_tunnel_key.h> has symbol
> > > > "TCA_ACT_TUNNEL_KEY": YES
> > > > Header <linux/tc_act/tc_tunnel_key.h> has symbol
> > > > "TCA_TUNNEL_KEY_ENC_DST_PORT": YES
> > > > Header <linux/tc_act/tc_tunnel_key.h> has symbol
> > > > "TCA_TUNNEL_KEY_NO_CSUM":
> > > > YES
> > > > Header <linux/tc_act/tc_pedit.h> has symbol
> > > > "TCA_PEDIT_KEY_EX_HDR_TYPE_UDP": YES
> > > > Header <rdma/rdma_netlink.h> has symbol "RDMA_NL_NLDEV": YES
> > > > Header <rdma/rdma_netlink.h> has symbol "RDMA_NLDEV_CMD_GET":
> > > > YES
> > > > Header <rdma/rdma_netlink.h> has symbol
> > > > "RDMA_NLDEV_CMD_PORT_GET":
> > > > YES
> > > > Header <rdma/rdma_netlink.h> has symbol
> > > > "RDMA_NLDEV_ATTR_DEV_INDEX": YES
> > > > Header <rdma/rdma_netlink.h> has symbol
> > > > "RDMA_NLDEV_ATTR_DEV_NAME":
> > > > YES
> > > > Header <rdma/rdma_netlink.h> has symbol
> > > > "RDMA_NLDEV_ATTR_PORT_INDEX": YES
> > > > Header <rdma/rdma_netlink.h> has symbol
> > > > "RDMA_NLDEV_ATTR_NDEV_INDEX": NO
> > > > Checking whether type "struct mlx5dv_sw_parsing_caps" has
> > > > member
> > > > "sw_parsing_offloads": YES
> > > > Checking whether type "struct ibv_counter_set_init_attr" has
> > > > member
> > > > "counter_set_id": YES
> > > > Checking whether type "struct ibv_counters_init_attr" has
> > > > member
> > > > "comp_mask": NO
> > > > Configuring mlx5_autoconf.h using configuration
> > > > Library libmusdk found: NO
> > > > Library libmusdk found: NO
> > > > Library pcap found: NO
> > > > Compiler for C supports argument -Wno-unused-parameter: YES
> > > > Compiler for C supports argument -Wno-sign-compare: YES
> > > > Compiler for C supports argument -Wno-missing-prototypes: YES
> > > > Compiler for C supports argument -Wno-cast-qual: YES
> > > > Compiler for C supports argument -Wno-unused-function: YES
> > > > Compiler for C supports argument -Wno-unused-variable: YES
> > > > Compiler for C supports argument -Wno-strict-aliasing: YES
> > > > Compiler for C supports argument -Wno-missing-prototypes: YES
> > > > Compiler for C supports argument -Wno-unused-value: YES
> > > > Compiler for C supports argument -Wno-format-nonliteral: YES
> > > > Compiler for C supports argument -Wno-shift-negative-value: YES
> > > > Compiler for C supports argument -Wno-unused-but-set-variable:
> > > > YES
> > > > Compiler for C supports argument -Wno-missing-declarations: YES
> > > > Compiler for C supports argument -Wno-maybe-uninitialized: YES
> > > > Compiler for C supports argument -Wno-strict-prototypes: YES
> > > > Compiler for C supports argument -Wno-shift-negative-value: YES
> > > > Compiler for C supports argument -Wno-implicit-fallthrough: YES
> > > > Compiler for C supports argument -Wno-format-extra-args: YES
> > > > Compiler for C supports argument -Wno-visibility: YES
> > > > Compiler for C supports argument -Wno-empty-body: YES
> > > > Compiler for C supports argument -Wno-invalid-source-encoding:
> > > > YES
> > > > Compiler for C supports argument -Wno-sometimes-uninitialized:
> > > > YES
> > > > Compiler for C supports argument -Wno-pointer-bool-conversion:
> > > > YES
> > > > Checking for size of "void *": 8
> > > > Compiler for C supports argument -Wno-strict-aliasing: YES
> > > > Compiler for C supports argument -Wextra: YES
> > > > Compiler for C supports argument -Wdisabled-optimization: YES
> > > > Compiler for C supports argument -Waggregate-return: YES
> > > > Compiler for C supports argument -Wnested-externs: YES
> > > > Compiler for C supports argument -Wbad-function-cast: YES
> > > > Compiler for C supports argument -Wno-sign-compare: YES
> > > > Compiler for C supports argument -Wno-unused-parameter: YES
> > > > Compiler for C supports argument -Wno-unused-variable: YES
> > > > Compiler for C supports argument -Wno-empty-body: YES
> > > > Compiler for C supports argument -Wno-unused-but-set-variable:
> > > > YES
> > > > Library sze2 found: NO
> > > > Header <linux/pkt_cls.h> has symbol "TCA_FLOWER_UNSPEC": YES
> > > > Header <linux/pkt_cls.h> has symbol "TCA_FLOWER_KEY_VLAN_PRIO":
> > > > YES
> > > > Header <linux/pkt_cls.h> has symbol "TCA_BPF_UNSPEC": YES
> > > > Header <linux/pkt_cls.h> has symbol "TCA_BPF_FD": YES
> > > > Header <linux/tc_act/tc_bpf.h> has symbol "TCA_ACT_BPF_UNSPEC":
> > > > YES
> > > > Header <linux/tc_act/tc_bpf.h> has symbol "TCA_ACT_BPF_FD": YES
> > > > Configuring tap_autoconf.h using configuration
> > > > Compiler for C supports argument -fno-prefetch-loop-arrays: YES
> > > > Compiler for C supports argument -Wno-maybe-uninitialized: YES
> > > > Compiler for C supports argument -Wall: YES
> > > > Compiler for C supports argument -Wextra: YES
> > > > Compiler for C supports argument -D_BSD_SOURCE: YES
> > > > Compiler for C supports argument -D_DEFAULT_SOURCE: YES
> > > > Compiler for C supports argument -D_XOPEN_SOURCE=600: YES
> > > > Compiler for C supports argument -Wno-unused-parameter: YES
> > > > Compiler for C supports argument -Wno-unused-value: YES
> > > > Compiler for C supports argument -Wno-strict-aliasing: YES
> > > > Compiler for C supports argument -Wno-format-extra-args: YES
> > > > Library IPSec_MB found: NO
> > > > Library IPSec_MB found: NO
> > > > Found pkg-config: /usr/bin/pkg-config (0.29.1)
> > > > Native dependency libcrypto found: YES 1.1.0g
> > > > Library libsso_kasumi found: NO
> > > > Library libmusdk found: NO
> > > > Dependency libcrypto found: YES (cached)
> > > > Dependency libcrypto found: YES (cached)
> > > > Library libsso_zuc found: NO
> > > > Dependency libisal found: NO
> > > > Dependency zlib found: NO
> > > > Compiler for C supports argument -Wno-sign-compare: YES
> > > > Compiler for C supports argument -Wno-unused-value: YES
> > > > Compiler for C supports argument -Wno-format: YES
> > > > Compiler for C supports argument -Wno-error=format-security:
> > > > YES
> > > > Compiler for C supports argument -Wno-strict-aliasing: YES
> > > > Compiler for C supports argument -Wno-unused-but-set-variable:
> > > > YES
> > > > Library execinfo found: NO
> > > > Compiler for C supports argument -Wno-format-truncation: YES
> > > > Dependency zlib found: NO
> > > > Library execinfo found: NO
> > > > Program doxygen found: NO
> > > > Program sphinx-build found: NO
> > > > kernel/linux/kni/meson.build:16: WARNING: Passed invalid
> > > > keyword
> > > > argument
> > > > "console".
> > > > WARNING: This will become a hard error in the future.
> > > > WARNING: Unknown keyword arguments in target rte_kni: console
> > > > Configuring rte_build_config.h using configuration
> > > > Program buildtools/symlink-drivers-solibs.sh found: YES
> > > > (/bin/sh
> > > > /home/cburdick/dpdk/buildtools/symlink-drivers-solibs.sh)
> > > > Message:
> > > > =================
> > > > Libraries Enabled
> > > > =================
> > > > 
> > > > libs:
> > > > \tcompat, cmdline, kvargs, eal, ring, mempool, mbuf, net,
> > > > \tethdev, pci, metrics, hash, timer, acl, bbdev, bitratestats,
> > > > \tcfgfile, compressdev, cryptodev, distributor, efd, eventdev,
> > > > gro,
> > > > gso,
> > > > \tip_frag, jobstats, kni, latencystats, lpm, member, meter,
> > > > power,
> > > > \tpdump, rawdev, reorder, sched, security, vhost, port, table,
> > > > \tpipeline, flow_classify, bpf,
> > > > 
> > > > Build targets in project: 411
> > > > Found ninja-1.8.2 at /usr/bin/ninja
> > > > [cburdick@dev01 ~/dpdk] (master)
> > > > $ cd build
> > > > [cburdick@dev01 ~/dpdk/build] (master)
> > > > $ ninja
> > > > [1428/1431] Generating igb_uio with a custom command.
> > > > make: Entering directory '/usr/src/linux-headers-4.15.0-20-
> > > > generic'
> > > > Makefile:976: "Cannot use CONFIG_STACK_VALIDATION=y, please
> > > > install
> > > > libelf-dev, libelf-devel or elfutils-libelf-devel"
> > > >   CC
> > > > [M]  /home/cburdick/dpdk/build/kernel/linux/igb_uio/igb_uio.o
> > > >   Building modules, stage 2.
> > > >   MODPOST 1 modules
> > > >  
> > > > CC      /home/cburdick/dpdk/build/kernel/linux/igb_uio/igb_uio.
> > > > mod.
> > > > o
> > > >   LD
> > > > [M]  /home/cburdick/dpdk/build/kernel/linux/igb_uio/igb_uio.ko
> > > > make: Leaving directory '/usr/src/linux-headers-4.15.0-20-
> > > > generic'
> > > > [1431/1431] Generating rte_kni with a custom command.
> > > > make: Entering directory '/usr/src/linux-headers-4.15.0-20-
> > > > generic'
> > > > Makefile:976: "Cannot use CONFIG_STACK_VALIDATION=y, please
> > > > install
> > > > libelf-dev, libelf-devel or elfutils-libelf-devel"
> > > >   CC [M]  /home/cburdick/dpdk/build/kernel/linux/kni/kni_net.o
> > > >   CC [M]  /home/cburdick/dpdk/build/kernel/linux/kni/kni_misc.o
> > > >   CC
> > > > [M]  /home/cburdick/dpdk/build/kernel/linux/kni/kni_ethtool.o
> > > >   CC [M]
> > > > /home/cburdick/dpdk/build/kernel/linux/kni/ethtool/ixgbe/ixgbe_
> > > > etht
> > > > ool.o
> > > >   CC [M]
> > > > /home/cburdick/dpdk/build/kernel/linux/kni/ethtool/ixgbe/ixgbe_
> > > > 8259
> > > > 9.o
> > > >   CC [M]
> > > > /home/cburdick/dpdk/build/kernel/linux/kni/ethtool/ixgbe/ixgbe_
> > > > api.
> > > > o
> > > >   CC [M]
> > > > /home/cburdick/dpdk/build/kernel/linux/kni/ethtool/ixgbe/ixgbe_
> > > > x540
> > > > .o
> > > >   CC [M]
> > > > /home/cburdick/dpdk/build/kernel/linux/kni/ethtool/ixgbe/ixgbe_
> > > > comm
> > > > on.o
> > > >   CC [M]
> > > > /home/cburdick/dpdk/build/kernel/linux/kni/ethtool/ixgbe/ixgbe_
> > > > phy.
> > > > o
> > > >   CC [M]
> > > > /home/cburdick/dpdk/build/kernel/linux/kni/ethtool/ixgbe/ixgbe_
> > > > 8259
> > > > 8.o
> > > >   CC [M]
> > > > /home/cburdick/dpdk/build/kernel/linux/kni/ethtool/ixgbe/ixgbe_
> > > > main
> > > > .o
> > > >   CC [M]
> > > > /home/cburdick/dpdk/build/kernel/linux/kni/ethtool/ixgbe/kcompa
> > > > t.o
> > > >   CC [M]
> > > > /home/cburdick/dpdk/build/kernel/linux/kni/ethtool/igb/e1000_82
> > > > 575.
> > > > o
> > > >   CC [M]
> > > > /home/cburdick/dpdk/build/kernel/linux/kni/ethtool/igb/e1000_i2
> > > > 10.o
> > > >   CC [M]
> > > > /home/cburdick/dpdk/build/kernel/linux/kni/ethtool/igb/e1000_mb
> > > > x.o
> > > >   CC [M]
> > > > /home/cburdick/dpdk/build/kernel/linux/kni/ethtool/igb/e1000_ap
> > > > i.o
> > > >   CC [M]
> > > > /home/cburdick/dpdk/build/kernel/linux/kni/ethtool/igb/igb_main
> > > > .o
> > > >   CC [M]
> > > > /home/cburdick/dpdk/build/kernel/linux/kni/ethtool/igb/igb_vmdq
> > > > .o
> > > >   CC [M]
> > > > /home/cburdick/dpdk/build/kernel/linux/kni/ethtool/igb/e1000_ma
> > > > nage
> > > > .o
> > > >   CC [M]
> > > > /home/cburdick/dpdk/build/kernel/linux/kni/ethtool/igb/igb_etht
> > > > ool.
> > > > o
> > > >   CC [M]
> > > > /home/cburdick/dpdk/build/kernel/linux/kni/ethtool/igb/igb_para
> > > > m.o
> > > >   CC [M]
> > > > /home/cburdick/dpdk/build/kernel/linux/kni/ethtool/igb/e1000_ma
> > > > c.o
> > > >   CC [M]
> > > > /home/cburdick/dpdk/build/kernel/linux/kni/ethtool/igb/e1000_ph
> > > > y.o
> > > >   CC [M]
> > > > /home/cburdick/dpdk/build/kernel/linux/kni/ethtool/igb/e1000_nv
> > > > m.o
> > > >   LD [M]  /home/cburdick/dpdk/build/kernel/linux/kni/rte_kni.o
> > > >   Building modules, stage 2.
> > > >   MODPOST 1 modules
> > > >  
> > > > CC      /home/cburdick/dpdk/build/kernel/linux/kni/rte_kni.mod.
> > > > o
> > > >   LD [M]  /home/cburdick/dpdk/build/kernel/linux/kni/rte_kni.ko
> > > > make: Leaving directory '/usr/src/linux-headers-4.15.0-20-
> > > > generic'
> > > > [cburdick@dev01 ~/dpdk/build] (master)
> > > > $ PKG_CONFIG_PATH=meson-private/ pkg-config --libs --static
> > > > libdpdk|grep
> > > > mlx
> > > > -L/usr/local/lib/x86_64-linux-gnu -lrte_flow_classify
> > > > -lrte_eventdev -
> > > > lrte_ip_frag -lrte_power -lrte_hash -lrte_pdump -lrte_pipeline
> > > > -lrte_table
> > > > -lrte_mbuf -lrte_bbdev -lrte_bpf -lrte_vhost -lrte_metrics
> > > > -lrte_mempool -
> > > > lrte_jobstats -lrte_reorder -lrte_net -lrte_security -lrte_eal
> > > > -lrte_ring
> > > > -lrte_ethdev -lrte_compressdev -lrte_rawdev -lrte_kvargs
> > > > -lrte_pci
> > > > -
> > > > lrte_cfgfile -lrte_gro -lrte_gso -lrte_cryptodev
> > > > -lrte_latencystats
> > > > -
> > > > lrte_sched -lrte_efd -lrte_distributor -lrte_acl -lrte_member -
> > > > lrte_cmdline -lrte_lpm -lrte_meter -lrte_kni -lrte_bitratestats
> > > > -
> > > > lrte_timer -lrte_port -lrte_mempool_bucket
> > > > -lrte_pmd_vdev_netvsc -
> > > > lrte_pmd_ark -lrte_pmd_failsafe -lrte_pmd_netvsc
> > > > -lrte_pmd_null_crypto -
> > > > lrte_bus_ifpga -lrte_common_dpaax -lrte_pmd_ixgbe
> > > > -lrte_mempool_ring -
> > > > lrte_pmd_kni -lrte_pmd_vmxnet3 -lrte_pmd_mlx4 -lrte_pmd_virtio
> > > > -Wl,--no-
> > > > as-needed -lrte_mempool_dpaa -lrte_pmd_ena -lrte_bus_fslmc
> > > > -lrte_pmd_avf -
> > > > lrte_pmd_dpaa2_sec -lrte_common_octeontx
> > > > -lrte_pmd_skeleton_rawdev
> > > > -
> > > > lrte_pmd_crypto_scheduler -lrte_pmd_dpaa2_qdma -lrte_pmd_vhost
> > > > -ldl
> > > > -
> > > > lrte_bus_dpaa -lrte_pmd_fm10k -lrte_pmd_bnxt -lrte_pmd_qat
> > > > -lrte_pmd_bond
> > > > -lrte_pmd_axgbe -lrte_pmd_dpaa2 -lrte_pmd_skeleton_event -
> > > > lrte_pmd_dpaa_event -lrte_mempool_stack -pthread -lrte_pmd_ccp
> > > > -
> > > > lrte_pmd_octeontx_compress -lrte_pmd_sw_event
> > > > -lrte_mempool_octeontx -Wl,-
> > > > Bdynamic -lrte_pmd_dpaa_sec -lrte_pmd_atlantic
> > > > -lrte_pmd_octeontx_event -
> > > > lrte_pmd_avp -lrte_bus_pci -lrte_pmd_dpaa2_cmdif -lrte_pmd_mlx5
> > > > -
> > > > lrte_pmd_opdl_event -lrte_pmd_tap -lrte_pmd_caam_jr
> > > > -lrte_pmd_sfc
> > > > -lcrypto
> > > > -lrte_pmd_enetc -lrte_mempool_dpaa2 -lrte_pmd_dpaa2_event
> > > > -lrte_pmd_ifc -
> > > > lrte_pmd_liquidio -lrte_pmd_cxgbe -lm -lrte_pmd_enic
> > > > -lrte_bus_vdev
> > > > -
> > > > lrte_pmd_e1000 -lrte_pmd_softnic -lrte_pmd_ifpga_rawdev
> > > > -lrte_bus_vmbus -
> > > > lrte_pmd_octeontx_crypto -lrte_pmd_null -lnuma -lrte_common_cpt
> > > > -
> > > > lrte_pmd_nfp -lrte_pmd_qede -lrte_pmd_i40e -lrte_pmd_dpaa -Wl,
> > > > --whole-
> > > > archive -lrte_pmd_bbdev_null -lrte_pmd_af_packet
> > > > -lrte_pmd_thunderx
> > > > -
> > > > lrte_pmd_openssl -lrte_pmd_octeontx -lrte_pmd_dsw_event -Wl,
> > > > --no-
> > > > whole-
> > > > archive -lrte_pmd_ring -lrte_pmd_virtio_crypto
> > > 
> > > That is strange. Can you try one last thing - can you update
> > > meson
> > > with "pip3 install --upgrade meson" and see if that makes any
> > > difference? [If you are using your distro's meson from /usr/bin
> > > right
> > > now, you'll probably also need to run "hash meson" afterwards
> > > too].
> > > Perhaps we have a hidden dependency on later meson versions or
> > > something like that.
> > > 
> > > /Bruce
> > 
> > We do - I can reproduce the same issue with 0.45.1, while normally
> > I
> > run 0.47.2. Should we bump the minimum version? Or simply document
> > it?
> > 
> 
> Bumping the minimum version would be really nice generally for DPDK,
> but I
> don't think this is the point in the release cycle to do so. I need
> to try
> and track down why this is broken with older mesons - most version
> specific
> things are harmless, and I'd like to keep it that way! 
> 
> If we can't fix this in rc4, then document, I suggest. That way we
> don't
> require absolutely everyone to use bleeding-edge meson.
> 
> /Bruce

I don't think it's anything we do, it's a feature Meson gained in 0.45:

"libraries: a list of built libraries (usually results of
shared_library) that the user needs to link against. Arbitrary strings
can also be provided and they will be added into the Libs field. Since
0.45.0 dependencies of built libraries will be automatically added to
Libs.private field. If a dependency is provided by pkg-config then it
will be added in Requires.private instead. Other type of dependency
objects can also be passed and will result in their link_args and
compile_args to be added to Libs and Cflags fields.

libraries_private: list of built libraries or strings to put in the
Libs.private field. Since 0.45.0 it can also contain dependency
objects, their link_args will be added to Libs.private."

https://mesonbuild.com/Pkgconfig-module.html

We could do all of that manually, but IMHO it's fine to document and
then bump the minimum version for 19.02. I'll send a patch to update
the doc, let me know if you prefer another solution.

-- 
Kind regards,
Luca Boccassi

Re: [dpdk-dev] [PATCH 1/1] eal: Don't fail secondary if primary is missing tailqs

[Bruce Richardson]

On Thu, Nov 15, 2018 at 06:22:07PM +0000, Luca Boccassi wrote:
> On Thu, 2018-11-15 at 17:17 +0000, Bruce Richardson wrote:
> > On Thu, Nov 15, 2018 at 05:05:16PM +0000, Luca Boccassi wrote:
> > > On Thu, 2018-11-15 at 17:01 +0000, Richardson, Bruce wrote:
> > > > > -----Original Message-----
> > > > > From: Burdick, Cliff [mailto:Cliff.Burdick@viasat.com]
> > > > > Sent: Thursday, November 15, 2018 4:55 PM
> > > > > To: Richardson, Bruce <bruce.richardson@intel.com>
> > > > > Cc: Luca Boccassi <bluca@debian.org>; Thomas Monjalon
> > > > > <thomas@monjalon.net>; Burakov, Anatoly <anatoly.burakov@intel.
> > > > > com>
> > > > > ;
> > > > > dev@dpdk.org
> > > > > Subject: RE: [dpdk-dev] [PATCH 1/1] eal: Don't fail secondary
> > > > > if
> > > > > primary
> > > > > is missing tailqs
> > > > > 
> > > > > 
> > > > > 
> > > > > -----Original Message-----
> > > > > From: Bruce Richardson [mailto:bruce.richardson@intel.com]
> > > > > Sent: Thursday, November 15, 2018 8:41 AM
> > > > > To: Burdick, Cliff
> > > > > Cc: Luca Boccassi; Thomas Monjalon; Burakov, Anatoly; dev@dpdk.
> > > > > org
> > > > > Subject: Re: [dpdk-dev] [PATCH 1/1] eal: Don't fail secondary
> > > > > if
> > > > > primary
> > > > > is missing tailqs
> > > > > 
> > > > > > On Thu, Nov 15, 2018 at 04:15:36PM +0000, Burdick, Cliff
> > > > > > wrote:
> > > > > > > 
> > > > > > > 
> > > > > > > -----Original Message-----
> > > > > > > From: Luca Boccassi [mailto:bluca@debian.org]
> > > > > > > Sent: Thursday, November 15, 2018 1:33 AM
> > > > > > > To: Burdick, Cliff; Bruce Richardson
> > > > > > > Cc: Thomas Monjalon; Burakov, Anatoly; dev@dpdk.org
> > > > > > > Subject: Re: [dpdk-dev] [PATCH 1/1] eal: Don't fail
> > > > > > > secondary
> > > > > > > if
> > > > > > > primary is missing tailqs
> > > > > > > 
> > > > > > > > On Wed, 2018-11-14 at 18:24 +0000, Burdick, Cliff wrote:
> > > > > > > > > 
> > > > > > > > > -----Original Message-----
> > > > > > > > > From: Luca Boccassi [mailto:bluca@debian.org]
> > > > > > > > > Sent: Wednesday, November 14, 2018 10:15 AM
> > > > > > > > > To: Burdick, Cliff; Bruce Richardson
> > > > > > > > > Cc: Thomas Monjalon; Burakov, Anatoly; dev@dpdk.org
> > > > > > > > > Subject: Re: [dpdk-dev] [PATCH 1/1] eal: Don't fail
> > > > > > > > > secondary if
> > > > > > > > > primary is missing tailqs
> > > > > > > > > 
> > > > > > > > > > On Wed, 2018-11-14 at 17:40 +0000, Burdick, Cliff
> > > > > > > > > > wrote:
> > > > > > > > > > > 
> > > > > > > > > > > -----Original Message-----
> > > > > > > > > > > From: Bruce Richardson [mailto:bruce.richardson@int
> > > > > > > > > > > el.c
> > > > > > > > > > > om]
> > > > > > > > > > > Sent: Wednesday, November 14, 2018 3:48 AM
> > > > > > > > > > > To: Burdick, Cliff
> > > > > > > > > > > Cc: Thomas Monjalon; Burakov, Anatoly; dev@dpdk.org
> > > > > > > > > > > Subject: Re: [dpdk-dev] [PATCH 1/1] eal: Don't fail
> > > > > > > > > > > secondary
> > > > > > > > > > > if primary is missing tailqs
> > > > > > > > > > > 
> > > > > > > > > > > On Tue, Nov 13, 2018 at 11:42:51PM +0000, Burdick,
> > > > > > > > > > > Cliff
> > > > > 
> > > > > wrote:
> > > > > > > > > > > > > 
> > > > > > > > > > > > > ________________________________________
> > > > > > > > > > > > > From: Thomas Monjalon [thomas@monjalon.net]
> > > > > > > > > > > > > Sent: Tuesday, November 13, 2018 2:18 PM
> > > > > > > > > > > > > To: Burdick, Cliff
> > > > > > > > > > > > > Cc: Burakov, Anatoly; dev@dpdk.org;
> > > > > > > > > > > > > bruce.richardson@intel.co m
> > > > > > > > > > > > > Subject: Re: [dpdk-dev] [PATCH 1/1] eal: Don't
> > > > > > > > > > > > > fail
> > > > > > > > > > > > > secondary if primary is missing tailqs
> > > > > > > > > > > > > 
> > > > > > > > > > > > > 13/11/2018 23:08, Burdick, Cliff:
> > > > > > > > > > > > > > From: Thomas Monjalon [mailto:thomas@monjalon
> > > > > > > > > > > > > > .net
> > > > > > > > > > > > > > ]
> > > > > > > > > > > > > > > 13/11/2018 17:38, Burdick, Cliff:
> > > > > > > > > > > > > > > > From: Thomas Monjalon [mailto:thomas@monj
> > > > > > > > > > > > > > > > alon
> > > > > > > > > > > > > > > > .net]
> > > > > > > > > > > > > > > > 13/11/2018 16:45, Burdick, Cliff:
> > > > > > > > > > > > > > > > > From: Burakov, Anatoly
> > > > > 
> > > > > [mailto:anatoly.burakov@intel.
> > > > > > > > > > > > > > > > > com]
> > > > > > > > > > > > > > > > > > On 13-Nov-18 9:21 AM, Thomas Monjalon
> > > > > > > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > > > > > > 13/11/2018 00:33, Burdick, Cliff:
> > > > > > > > > > > > > > > > > > > > This patch was submitted by Jean
> > > > > > > > > > > > > > > > > > > > Tourrilhes
> > > > > > > > > > > > > > > > > > > > over two years ago, but didn't
> > > > > > > > > > > > > > > > > > > > receive any
> > > > > 
> > > > > responses.
> > > > > > > > > > > > > > > > > > > > I hit the same issue recently
> > > > > > > > > > > > > > > > > > > > when
> > > > > > > > > > > > > > > > > > > > trying to
> > > > > > > > > > > > > > > > > > > > use cgo
> > > > > > > > > > > > > > > > > > > > (Golang) as a primary process
> > > > > > > > > > > > > > > > > > > > linked
> > > > > > > > > > > > > > > > > > > > to
> > > > > > > > > > > > > > > > > > > > libdpdk.a against a C++
> > > > > > > > > > > > > > > > > > > > application
> > > > > > > > > > > > > > > > > > > > linked
> > > > > > > > > > > > > > > > > > > > against the same library.> > >
> > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > The question is to know why you
> > > > > > > > > > > > > > > > > > > don't
> > > > > > > > > > > > > > > > > > > have the
> > > > > > > > > > > > > > > > > > > same constructors in primary and
> > > > > > > > > > > > > > > > > > > seconday?
> > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > I've hit similar things in the past.
> > > > > > > > > > > > > > > > > > I
> > > > > > > > > > > > > > > > > > believe
> > > > > > > > > > > > > > > > > > it was caused by our build system
> > > > > > > > > > > > > > > > > > stripping out
> > > > > > > > > > > > > > > > > > unused libraries (such as
> > > > > > > > > > > > > > > > > > rte_hash) from the binary and thus
> > > > > > > > > > > > > > > > > > not
> > > > > > > > > > > > > > > > > > calling
> > > > > > > > > > > > > > > > > > the constructor in the primary, but
> > > > > > > > > > > > > > > > > > doing
> > > > > > > > > > > > > > > > > > so in
> > > > > > > > > > > > > > > > > > the secondary (or something to that
> > > > > > > > > > > > > > > > > > effect). In
> > > > > > > > > > > > > > > > > > any case, this is caused by linking
> > > > > > > > > > > > > > > > > > different
> > > > > > > > > > > > > > > > > > number of libraries to primary and
> > > > > > > > > > > > > > > > > > secondary,
> > > > > > > > > > > > > > > > > > and should probably be fixed in the
> > > > > > > > > > > > > > > > > > build
> > > > > > > > > > > > > > > > > > system, not in the tailqs code
> > > > > > > > > > > > > > > > > > (unless we
> > > > > > > > > > > > > > > > > > specifically support having different
> > > > > > > > > > > > > > > > > > linked
> > > > > > > > > > > > > > > > > > libraries to primary and
> > > > > > > > > > > > > > > > > > secondary?).> >
> > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > Right, I think the original author of
> > > > > > > > > > > > > > > > > the
> > > > > > > > > > > > > > > > > patch
> > > > > > > > > > > > > > > > > stated the reasons in the link I
> > > > > > > > > > > > > > > > > provided.
> > > > > > > > > > > > > > > > > The
> > > > > > > > > > > > > > > > > build system seems like the most
> > > > > > > > > > > > > > > > > appropriate place
> > > > > > > > > > > > > > > > > to fix it, but the patch got me going
> > > > > > > > > > > > > > > > > quickly. I
> > > > > > > > > > > > > > > > > think the question is whether you want
> > > > > > > > > > > > > > > > > DPDK
> > > > > > > > > > > > > > > > > to
> > > > > > > > > > > > > > > > > support these other ways of linking.
> > > > > > > > > > > > > > > > > I'm
> > > > > > > > > > > > > > > > > certainly not the first to use cgo,
> > > > > > > > > > > > > > > > > since
> > > > > > > > > > > > > > > > > there's
> > > > > > > > > > > > > > > > > a virtual switch project doing the
> > > > > > > > > > > > > > > > > same:
> > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > https://urldefense.proofpoint.com/v2/ur
> > > > > > > > > > > > > > > > > l?u=
> > > > > > > > > > > > > > > > > https-3
> > > > > > > > > > > > > > > > > A__
> > > > > > > > > > > > > > > > > gith
> > > > > > > > > > > > > > > > > ub.co
> > > > > > > > > > > > > > > > > m_lago
> > > > > > > > > > > > > > > > > pu
> > > > > > > > > > > > > > > > > s_vsw&d=DwICAg&c=jcv3orpCsv7C4ly8-
> > > > > > > > > > > > > > > > > ubDoUfrxF5xIGWmptxGWP5vi5w&r =m1RLQ OG
> > > > > > > > > > > > > > > > > Okz9MauvVLZmiGtyWc5mA7DejbPFNE1IDj-
> > > > > > > > > > > > > > > > > 4&m=hQqVCNwW7eoEzB_hLFK97i8 idS8FI qX
> > > > > > > > > > > > > > > > > oPeclwsIZq7Y&s=BMoBlwkqljwWIBY3SE3pPMCf
> > > > > > > > > > > > > > > > > VnOU
> > > > > > > > > > > > > > > > > lDuZLrn
> > > > > > > > > > > > > > > > > o4-
> > > > > > > > > > > > > > > > > SojKM&e=
> > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > They don't use primary/secondary
> > > > > > > > > > > > > > > > > processes,
> > > > > > > > > > > > > > > > > though, so the issue is  never hit. I'm
> > > > > > > > > > > > > > > > > in
> > > > > > > > > > > > > > > > > a
> > > > > > > > > > > > > > > > > situation where using cgo seemed like
> > > > > > > > > > > > > > > > > the
> > > > > > > > > > > > > > > > > easiest
> > > > > > > > > > > > > > > > > path to accomplish what I'm doing since
> > > > > > > > > > > > > > > > > I
> > > > > > > > > > > > > > > > > needed
> > > > > > > > > > > > > > > > > specialized  libraries for it that were
> > > > > > > > > > > > > > > > > not
> > > > > > > > > > > > > > > > > available in C/C++. At some point
> > > > > > > > > > > > > > > > > I  bet
> > > > > > > > > > > > > > > > > someone
> > > > > > > > > > > > > > > > > would use Cython to start linking
> > > > > > > > > > > > > > > > > against
> > > > > > > > > > > > > > > > > DPDK as
> > > > > > > > > > > > > > > > > well,  and we'd likely run into the
> > > > > > > > > > > > > > > > > same
> > > > > > > > > > > > > > > > > issue.> >
> > > > > > > > > > > > > > > > > > > For sure, we want to support using
> > > > > > > > > > > > > > > > > > > DPDK
> > > > > > > > > > > > > > > > > > > with
> > > > > 
> > > > > cgo or cython.
> > > > > > > > > > > > > > > > > But it is not clear what is the
> > > > > > > > > > > > > > > > > relation
> > > > > > > > > > > > > > > > > with not
> > > > > > > > > > > > > > > > > having the same compilation for primary
> > > > > > > > > > > > > > > > > and
> > > > > 
> > > > > secondary.
> > > > > > > > > > > > > > > > > Please
> > > > > > > > > > > > > > > > > could you elaborate?> > >
> > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > Hi Thomas, I think Jean explained it well
> > > > > > > > > > > > > > > > here:
> > > > > > > > > > > > > > > > https://urldefense.proofpoint.com/v2/url?
> > > > > > > > > > > > > > > > u=ht
> > > > > > > > > > > > > > > > tps-3A_
> > > > > > > > > > > > > > > > _de
> > > > > > > > > > > > > > > > v.dp
> > > > > > > > > > > > > > > > dk.narkive.
> > > > > > > > > > > > > > > > com_ZM3a7QD1_dpdk-2Ddev-2Dbug-2Dstatic-
> > > > > > > > > > > > > > > > 2Dconstructor
> > > > > > > > > > > > > > > > s-
> > > > > > > > > > > > > > > > 2Dconsider
> > > > > > > > > > > > > > > > ed-2De
> > > > > > > > > > > > > > > > vil&d=DwICAg&c=jcv3orpCsv7C4ly8-
> > > > > > > > > > > > > > > > ubDoUfrxF5xIGWmptxGWP5vi5w&r=m1R LQOGOk
> > > > > > > > > > > > > > > > z9MauvVLZmiGtyWc5mA7DejbPFNE1IDj-
> > > > > > > > > > > > > > > > 4&m=C69wDgrjDX8_oXp1M_3bnmWOOZd GqwBBG
> > > > > > > > > > > > > > > > 9vzkyGDWGQ&s=YYn2N7WrzJpH1ptNrLZad0nPAQdr
> > > > > > > > > > > > > > > > UyqB
> > > > > > > > > > > > > > > > ckk2uFu
> > > > > > > > > > > > > > > > WYP
> > > > > > > > > > > > > > > > Q&e=
> > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > "The build system of the application does
> > > > > > > > > > > > > > > > not
> > > > > > > > > > > > > > > > have
> > > > > > > > > > > > > > > > all the subtelties of the DPDK build
> > > > > > > > > > > > > > > > system,
> > > > > > > > > > > > > > > > and
> > > > > > > > > > > > > > > > ends up including
> > > > > > > > > > > > > > > > *all*
> > > > > > > > > > > > > > > > the constructors, wether they are used or
> > > > > > > > > > > > > > > > not
> > > > > > > > > > > > > > > > in the
> > > > > > > > > > > > > > > > code.
> > > > > > > > > > > > > > > > Moreover, they are included in a
> > > > > > > > > > > > > > > > different
> > > > > > > > > > > > > > > > order.
> > > > > > > > > > > > > > > > Actually,
> > > > > > > > > > > > > > > > by default the builds include no
> > > > > > > > > > > > > > > > constructors
> > > > > > > > > > > > > > > > at all
> > > > > > > > > > > > > > > > (which is a big fail), so the library
> > > > > > > > > > > > > > > > needs
> > > > > > > > > > > > > > > > to be
> > > > > > > > > > > > > > > > included with --whole-archive (see Snort
> > > > > > > > > > > > > > > > DPDK
> > > > > > > > > > > > > > > > instructions)."
> > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > I will get to the bottom of my exact case
> > > > > > > > > > > > > > > > to
> > > > > > > > > > > > > > > > understand what's happening, but my
> > > > > > > > > > > > > > > > primary
> > > > > > > > > > > > > > > > application is a cgo application that I'm
> > > > > > > > > > > > > > > > linking to
> > > > > > > > > > > > > > > > by using almost exactly the same flags
> > > > > > > > > > > > > > > > that
> > > > > > > > > > > > > > > > are used
> > > > > > > > > > > > > > > > in the DPDK build system to build
> > > > > > > > > > > > > > > > examples.
> > > > > > > > > > > > > > > > The DPDK
> > > > > > > > > > > > > > > > libraries I'm linking against is a single
> > > > > > > > > > > > > > > > location
> > > > > > > > > > > > > > > > for both primary and secondary; in other
> > > > > > > > > > > > > > > > words, I
> > > > > 
> > > > > don't build DPDK twice.
> > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > OK I understand, thanks.
> > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > You had alluded to a pkg-config for DPDK
> > > > > > > > > > > > > > > > in
> > > > > > > > > > > > > > > > the 2015
> > > > > > > > > > > > > > > > thread, which cgo can use, but I don't
> > > > > > > > > > > > > > > > know
> > > > > > > > > > > > > > > > if that
> > > > > > > > > > > > > > > > ever was implemented. Cgo can use pkg-
> > > > > > > > > > > > > > > > config
> > > > > > > > > > > > > > > > if it's
> > > > > > > > > > > > > > > > available, otherwise the only tools are
> > > > > > > > > > > > > > > > specifying
> > > > > > > > > > > > > > > > LDFLAGS and CFLAGS into their build
> > > > > > > > > > > > > > > > system.
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > Yes, the right answer is still pkg-config
> > > > > > > > > > > > > > > :)
> > > > > > > > > > > > > > > The good
> > > > > > > > > > > > > > > news is that it is now implemented thanks
> > > > > > > > > > > > > > > to
> > > > > > > > > > > > > > > the meson
> > > > > > > > > > > > > > > build
> > > > > > > > > > > > > > > system:
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > https://urldefense.proofpoint.com/v2/url?u=
> > > > > > > > > > > > > > > http
> > > > > > > > > > > > > > > -3A__gi
> > > > > > > > > > > > > > > t.d
> > > > > > > > > > > > > > > pdk.
> > > > > > > > > > > > > > > org_dp
> > > > > > > > > > > > > > > dk_tree_doc_build-2Dsdk-2Dmeson.txt-
> > > > > > > > > > > > > > > 23n182&d=DwICAg&c=jcv3orpCsv7C4
> > > > > > > > > > > > > > > ly8-
> > > > > > > > > > > > > > > ubDoUfrxF5xIGWmptxGWP5vi5w&r=m1RLQOGOkz9Mau
> > > > > > > > > > > > > > > vVLZ
> > > > > > > > > > > > > > > miGtyWc
> > > > > > > > > > > > > > > 5mA
> > > > > > > > > > > > > > > 7Dej
> > > > > > > > > > > > > > > bP
> > > > > > > > > > > > > > > FNE1IDj-
> > > > > > > > > > > > > > > > 4&m=C69wDgrjDX8_oXp1M_3bnmWOOZdGqwBBG9vzk
> > > > > > > > > > > > > > > > yGDW
> > > > > > > > > > > > > > > > GQ&s=oC
> > > > > > > > > > > > > > > > 86K
> > > > > > > > > > > > > > > > D_R
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > J1T6rfzi3x5zFT1Ri13ELpKmsyFqpgDbgFg&e=
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > Hi Thomas, are there instructions on how to
> > > > > > > > > > > > > > use
> > > > > > > > > > > > > > pkg-config to build the mlx4/5 PMD? I noticed
> > > > > > > > > > > > > > a
> > > > > > > > > > > > > > patch
> > > > > > > > > > > > > > was submitted in September to add support for
> > > > > > > > > > > > > > it,
> > > > > > > > > > > > > > but
> > > > > > > > > > > > > > that link you provided on using meson doesn't
> > > > > > > > > > > > > > say
> > > > > > > > > > > > > > how to
> > > > > > > > > > > > > > build specific drivers. It appears to be
> > > > > > > > > > > > > > disabled
> > > > > > > > > > > > > > by
> > > > > 
> > > > > default.
> > > > > > > > > > > > > > If the dependency is found, meson will enable
> > > > > > > > > > > > > > the
> > > > > > > > > > > > > > PMD
> > > > > > > > > > > > > > when building DPDK.
> > > > > > > > > > > > > 
> > > > > > > > > > > > > Do you know where exactly that is? I've been
> > > > > > > > > > > > > using
> > > > > > > > > > > > > mlx5
> > > > > > > > > > > > > for a while on this system, and I can see that
> > > > > > > > > > > > > 18.11-rc2
> > > > > > > > > > > > > meson
> > > > > > > > > > > > > build+ninja built the pmd, but it's not on the
> > > > > > > > > > > > > --
> > > > > > > > > > > > > libs
> > > > > > > > > > > > > build+listing
> > > > > > > > > > > > > for
> > > > > > > > > > > > > pkg-config. Does it tell me what I was missing?
> > > > > > > > > > > > > 
> > > > > > > > > > > > 
> > > > > > > > > > > > For dynamic linking of applications, the drivers
> > > > > > > > > > > > are
> > > > > > > > > > > > not
> > > > > > > > > > > > normally linked in. Instead, they should be
> > > > > > > > > > > > loaded
> > > > > > > > > > > > from the
> > > > > > > > > > > > drivers directory as .so files
> > > > > > > > > > > > - normally by default in EAL as the driver .so's
> > > > > > > > > > > > should be
> > > > > > > > > > > > copied to the EAL_PMD_PATH where EAL finds them
> > > > > 
> > > > > automatically.
> > > > > > > > > > > > [This applies to both meson and make builds,
> > > > > > > > > > > > though
> > > > > > > > > > > > only
> > > > > > > > > > > > meson generates the .pc file for pkg-config]
> > > > > > > > > > > > 
> > > > > > > > > > > > If you are doing a static build, then you need to
> > > > > > > > > > > > explicitly
> > > > > > > > > > > > link in the drivers. You can get a list from pkg-
> > > > > > > > > > > > config
> > > > > > > > > > > > using the "
> > > > > > > > > > > > --static" flag in this case. A good example of
> > > > > > > > > > > > how to
> > > > > > > > > > > > use
> > > > > > > > > > > > pkg- config in this way can be found in the
> > > > > > > > > > > > Makefiles
> > > > > > > > > > > > for
> > > > > > > > > > > > most examples, e.g. examples/helloworld/Makefile,
> > > > > > > > > > > > reproduced
> > > > > 
> > > > > below.
> > > > > > > > > > > > 
> > > > > > > > > > > > Regards,
> > > > > > > > > > > > /Bruce
> > > > > > > > > > > > 
> > > > > > > > > > > > all: shared
> > > > > > > > > > > > .PHONY: shared static
> > > > > > > > > > > > shared: build/$(APP)-shared
> > > > > > > > > > > >         ln -sf $(APP)-shared build/$(APP)
> > > > > > > > > > > > static: build/$(APP)-static
> > > > > > > > > > > >         ln -sf $(APP)-static build/$(APP)
> > > > > > > > > > > > 
> > > > > > > > > > > > PC_FILE := $(shell pkg-config --path libdpdk)
> > > > > > > > > > > > CFLAGS
> > > > > > > > > > > > += -O3
> > > > > > > > > > > > $(shell pkg-config --cflags libdpdk)
> > > > > > > > > > > > LDFLAGS_SHARED =
> > > > > > > > > > > > $(shell
> > > > > > > > > > > > pkg- config -- libs libdpdk) LDFLAGS_STATIC =
> > > > > > > > > > > > -Wl,-
> > > > > > > > > > > > Bstatic
> > > > > > > > > > > > $(shell pkg-config
> > > > > > > > > > > > --
> > > > > > > > > > > > static --libs libdpdk)
> > > > > > > > > > > > 
> > > > > > > > > > > > build/$(APP)-shared: $(SRCS-y) Makefile
> > > > > > > > > > > > $(PC_FILE) |
> > > > > > > > > > > > build
> > > > > > > > > > > >         $(CC) $(CFLAGS) $(SRCS-y) -o $@
> > > > > > > > > > > > $(LDFLAGS)
> > > > > > > > > > > > $(LDFLAGS_SHARED)
> > > > > > > > > > > > 
> > > > > > > > > > > > build/$(APP)-static: $(SRCS-y) Makefile
> > > > > > > > > > > > $(PC_FILE) |
> > > > > > > > > > > > build
> > > > > > > > > > > >         $(CC) $(CFLAGS) $(SRCS-y) -o $@
> > > > > > > > > > > > $(LDFLAGS)
> > > > > > > > > > > > $(LDFLAGS_STATIC)
> > > > > > > > > > > > 
> > > > > > > > > > > > build:
> > > > > > > > > > > >         @mkdir -p $@
> > > > > > > > > > > 
> > > > > > > > > > > Thanks Bruce. I tried getting this to compile using
> > > > > > > > > > > cgo, and
> > > > > > > > > > > it's causing more pain than it's worth. I used the
> > > > > > > > > > > --
> > > > > > > > > > > static
> > > > > > > > > > > --libs options, and there were still numerous
> > > > > > > > > > > linker
> > > > > > > > > > > errors,
> > > > > > > > > > > some specific to mlx, and some not. Specifically
> > > > > > > > > > > libmlx5 and
> > > > > > > > > > > libmnl are both needed, but they're not part of the
> > > > > > > > > > > linker
> > > > > > > > > > > line from pkg-config. At this point I'll just break
> > > > > > > > > > > the
> > > > > > > > > > > Go
> > > > > > > > > > > application up into a separate C application that
> > > > > > > > > > > handles all
> > > > > > > > > > > the DPDK parts, and send messages between them.
> > > > > > > > > > 
> > > > > > > > > > Hi,
> > > > > > > > > > 
> > > > > > > > > > As far as I can see, both mnl and mlx5 (and all the
> > > > > > > > > > other
> > > > > > > > > > reverse
> > > > > > > > > > dependencies) are listed correctly in the libdpdk.pc
> > > > > > > > > > Libs.private entry, and pkg-config --libs --static
> > > > > > > > > > libdpdk.pc
> > > > > > > > > > does print them as intended. This is with 18.11-rc3.
> > > > > > > > > > Are you sure everything is correct (pkg-config path
> > > > > > > > > > is
> > > > > > > > > > right, --
> > > > > > > > > > static is used, etc)?
> > > > > > > > > > 
> > > > > > > > > > --
> > > > > > > > > > Kind regards,
> > > > > > > > > > Luca Boccassi
> > > > > > > > > 
> > > > > > > > > Hi Luca, here is what pkg-config gives:
> > > > > > > > > 
> > > > > > > > > PKG_CONFIG_PATH=meson-private/ pkg-config --libs --
> > > > > > > > > static
> > > > > > > > > libdpdk
> > > > > > > > > -L/usr/local/lib/x86_64-linux-gnu -lrte_eventdev
> > > > > > > > > -lrte_power
> > > > > > > > > -lrte_ip_frag -lrte_hash -lrte_pdump -lrte_eal
> > > > > > > > > -lrte_pipeline
> > > > > > > > > -lrte_table -lrte_bbdev -lrte_bpf -lrte_vhost
> > > > > > > > > -lrte_metrics
> > > > > > > > > -lrte_jobstats -lrte_net -lrte_reorder -lrte_ring
> > > > > > > > > -lrte_mempool
> > > > > > > > > -lrte_security -lrte_compressdev -lrte_rawdev
> > > > > > > > > -lrte_mbuf
> > > > > > > > > -lrte_kvargs -lrte_port -lrte_pci -lrte_ethdev
> > > > > > > > > -lrte_gro
> > > > > > > > > -lrte_gso
> > > > > > > > > -lrte_cryptodev -lrte_sched -lrte_latencystats
> > > > > > > > > -lrte_efd
> > > > > > > > > -lrte_distributor -lrte_meter -lrte_acl -lrte_member
> > > > > > > > > -lrte_cmdline
> > > > > > > > > -lrte_lpm -lrte_kni -lrte_cfgfile -lrte_bitratestats
> > > > > > > > > -lrte_timer
> > > > > > > > > -lrte_flow_classify -lrte_mempool_bucket
> > > > > > > > > -lrte_pmd_null_crypto
> > > > > > > > > -lrte_pmd_failsafe -lrte_bus_ifpga -lrte_pmd_atlantic
> > > > > > > > > -lrte_pmd_mlx4 -lrte_pmd_vmxnet3 -lrte_pmd_avp
> > > > > > > > > -lrte_common_dpaax
> > > > > > > > > -lrte_pmd_ena -lcrypto -lrte_bus_fslmc -ldl
> > > > > > > > > -lrte_pmd_avf
> > > > > > > > > -lrte_pmd_crypto_scheduler -lrte_pmd_netvsc
> > > > > > > > > -lrte_pmd_vhost
> > > > > > > > > -lrte_bus_dpaa -lrte_mempool_dpaa2
> > > > > > > > > -lrte_common_octeontx
> > > > > > > > > -lrte_pmd_liquidio -lrte_pmd_ifc -Wl,-Bdynamic -lnuma
> > > > > > > > > -lrte_pmd_enic -lrte_common_cpt -pthread
> > > > > > > > > -lrte_pmd_octeontx_crypto
> > > > > > > > > -lrte_pmd_qat -lrte_bus_vmbus -lrte_pmd_null -lm
> > > > > > > > > -lrte_pmd_dpaa
> > > > > > > > > -lrte_bus_vdev -lrte_pmd_dpaa2 -lrte_pmd_skeleton_event
> > > > > > > > > -lrte_pmd_af_packet -lrte_pmd_octeontx
> > > > > > > > > -lrte_pmd_thunderx
> > > > > > > > > -lrte_pmd_ring -lrte_pmd_octeontx_event
> > > > > > > > > -lrte_pmd_sw_event
> > > > > > > > > -lrte_pmd_ark -lrte_mempool_octeontx -lrte_pmd_ixgbe
> > > > > > > > > -lrte_pmd_kni
> > > > > > > > > -lrte_mempool_ring -lrte_pmd_virtio_crypto
> > > > > > > > > -lrte_mempool_dpaa
> > > > > > > > > -lrte_pmd_dpaa2_cmdif -lrte_bus_pci
> > > > > > > > > -lrte_pmd_opdl_event
> > > > > > > > > -lrte_pmd_mlx5 -lrte_pmd_virtio -lrte_pmd_tap
> > > > > > > > > -lrte_pmd_caam_jr
> > > > > > > > > -lrte_pmd_dpaa2_sec -lrte_pmd_dpaa2_qdma
> > > > > > > > > -lrte_pmd_enetc
> > > > > > > > > -lrte_pmd_sfc -lrte_pmd_bnxt -lrte_pmd_dpaa2_event
> > > > > > > > > -lrte_pmd_cxgbe
> > > > > > > > > -Wl,--whole-archive -Wl,--no- as-needed -lrte_pmd_e1000
> > > > > > > > > -lrte_pmd_softnic -lrte_pmd_bond -lrte_pmd_fm10k
> > > > > > > > > -lrte_pmd_i40e
> > > > > > > > > -lrte_pmd_nfp -lrte_pmd_qede -Wl,--no- whole-archive
> > > > > > > > > -lrte_pmd_axgbe -lrte_pmd_ccp -lrte_pmd_ifpga_rawdev
> > > > > > > > > -lrte_pmd_bbdev_null -lrte_pmd_openssl
> > > > > > > > > -lrte_pmd_dsw_event
> > > > > > > > > -lrte_pmd_dpaa_event -lrte_mempool_stack
> > > > > > > > > -lrte_pmd_vdev_netvsc
> > > > > > > > > -lrte_pmd_dpaa_sec -lrte_pmd_skeleton_rawdev
> > > > > > > > > -lrte_pmd_octeontx_compress
> > > > > > > > > 
> > > > > > > > > You'll notice there's no mlx5 or mnl in that list. I
> > > > > > > > > was
> > > > > > > > > using
> > > > > > > > > 18.11-
> > > > > > > > > rc2 since I cloned early yesterday. Perhaps meson
> > > > > > > > > determined not
> > > > > > > > > to put it in there for some reason?
> > > > > > > > 
> > > > > > > > Were mlx5/mnl found at meson configure time?
> > > > > > > > 
> > > > > > > > --
> > > > > > > > Kind regards,
> > > > > > > > Luca Boccassi
> > > > > > > 
> > > > > > > Hi Luca, yes, it was:
> > > > > > > 
> > > > > > > Library mnl found: YES
> > > > > > > Library mlx4 found: YES
> > > > > > > Library ibverbs found: YES
> > > > > > > Compiler for C supports argument -Wextra: YES Compiler for
> > > > > > > C
> > > > > > > supports
> > > > > > > argument -std=c11: YES Compiler for C supports argument
> > > > > > > -Wno-strict-prototypes: YES Compiler for C supports
> > > > > > > argument
> > > > > > > -D_BSD_SOURCE: YES Compiler for C supports argument
> > > > > > > -D_DEFAULT_SOURCE:
> > > > > > > YES Compiler for C supports argument -D_XOPEN_SOURCE=600:
> > > > > > > YES
> > > > > > > Checking
> > > > > > > whether type "struct mlx4_wqe_lso_seg" has member
> > > > > > > "mss_hdr_size": YES
> > > > > > > Configuring mlx4_autoconf.h using configuration Library mnl
> > > > > > > found: YES
> > > > > > > Library mlx5 found: YES Library ibverbs found: YES ...
> > > > > > > PKG_CONFIG_PATH=meson-private/ pkg-config --libs --static
> > > > > > > libdpdk
> > > > > > > -L/usr/local/lib/x86_64-linux-gnu -lrte_eventdev
> > > > > > > -lrte_power
> > > > > > > -lrte_ip_frag -lrte_hash -lrte_pdump -lrte_eal
> > > > > > > -lrte_pipeline
> > > > > > > -lrte_table -lrte_bbdev -lrte_bpf -lrte_vhost -lrte_metrics
> > > > > > > -lrte_jobstats -lrte_net -lrte_reorder -lrte_ring
> > > > > > > -lrte_mempool
> > > > > > > -lrte_security -lrte_compressdev -lrte_rawdev -lrte_mbuf
> > > > > > > -lrte_kvargs
> > > > > > > -lrte_port -lrte_pci -lrte_ethdev -lrte_gro -lrte_gso
> > > > > > > -lrte_cryptodev
> > > > > > > -lrte_sched -lrte_latencystats -lrte_efd -lrte_distributor
> > > > > > > -lrte_meter
> > > > > > > -lrte_acl -lrte_member -lrte_cmdline -lrte_lpm -lrte_kni
> > > > > > > -lrte_cfgfile
> > > > > > > -lrte_bitratestats -lrte_timer -lrte_flow_classify
> > > > > > > -lrte_pmd_ccp
> > > > > > > -lrte_mempool_bucket -lrte_pmd_failsafe -lrte_pmd_netvsc
> > > > > > > -lrte_pmd_null_crypto -lrte_bus_ifpga -lrte_pmd_atlantic
> > > > > > > -lrte_pmd_octeontx_event -lrte_pmd_avp -lrte_pmd_mlx4
> > > > > > > -lrte_common_dpaax -lrte_pmd_skeleton_rawdev -lrte_pmd_ena
> > > > > > > -lrte_pmd_opdl_event -lrte_bus_fslmc -lnuma -lrte_pmd_avf
> > > > > > > -lrte_pmd_crypto_scheduler -lrte_pmd_vhost -lrte_bus_dpaa
> > > > > > > -lrte_mempool_dpaa2 -lrte_common_octeontx -Wl,--no-as-
> > > > > > > needed
> > > > > > > -lcrypto
> > > > > > > -lrte_pmd_ifc -lrte_pmd_liquidio -lrte_pmd_enic
> > > > > > > -lrte_common_cpt
> > > > > > > -Wl,--no-whole-archive -lrte_bus_vmbus
> > > > > > > -lrte_pmd_octeontx_crypto
> > > > > > > -lrte_pmd_qat -lrte_pmd_ifpga_rawdev -lrte_pmd_dpaa
> > > > > > > -lrte_bus_vdev
> > > > > > > -lrte_pmd_bbdev_null -lrte_pmd_dpaa2
> > > > > > > -lrte_pmd_skeleton_event
> > > > > > > -lrte_pmd_ring -lrte_pmd_af_packet -lrte_pmd_thunderx
> > > > > > > -lrte_pmd_dpaa_event -lrte_pmd_octeontx_compress
> > > > > > > -lrte_pmd_dpaa_sec
> > > > > > > -lrte_pmd_sw_event -Wl,--whole-archive -lrte_pmd_ark
> > > > > > > -lrte_mempool_octeontx -lrte_pmd_ixgbe -lrte_mempool_ring
> > > > > > > -lrte_pmd_kni -lrte_pmd_vmxnet3 -lrte_mempool_dpaa
> > > > > > > -lrte_bus_pci
> > > > > > > -lrte_pmd_dpaa2_cmdif -lrte_pmd_mlx5 -lrte_pmd_tap
> > > > > > > -lrte_pmd_caam_jr
> > > > > > > -lrte_pmd_dpaa2_sec -lm -lrte_pmd_dpaa2_qdma
> > > > > > > -lrte_pmd_enetc
> > > > > > > -lrte_pmd_virtio -lrte_pmd_bnxt -lrte_pmd_dpaa2_event
> > > > > > > -lrte_pmd_sfc
> > > > > > > -lrte_pmd_cxgbe -pthread -lrte_pmd_e1000 -lrte_pmd_softnic
> > > > > > > -ldl
> > > > > > > -lrte_pmd_null -lrte_pmd_bond -lrte_pmd_fm10k
> > > > > > > -lrte_pmd_i40e
> > > > > > > -lrte_pmd_nfp -lrte_pmd_qede -lrte_pmd_axgbe -Wl,-Bdynamic
> > > > > > > -lrte_pmd_openssl -lrte_pmd_octeontx -lrte_pmd_dsw_event
> > > > > > > -lrte_mempool_stack -lrte_pmd_virtio_crypto
> > > > > > > -lrte_pmd_vdev_netvsc
> > > > > > 
> > > > > > Is this with latest DPDK from git? because I see the exact
> > > > > > same
> > > > > > as Luca:
> > > > > > 
> > > > > > $ PKG_CONFIG_PATH=build/meson-private/ pkg-config --libs --
> > > > > > static
> > > > > 
> > > > > libdpdk | grep mlx
> > > > > > -L/usr/local/lib64 -lrte_telemetry -lrte_bpf
> > > > > > -lrte_flow_classify
> > > > > > -
> > > > > 
> > > > > lrte_pipeline -lrte_table -lrte_port -lrte_vhost -lrte_security
> > > > > -
> > > > > lrte_sched -lrte_reorder -lrte_rawdev -lrte_pdump -lrte_power
> > > > > -lrte_meter
> > > > > -lrte_member -lrte_lpm -lrte_latencystats -lrte_kni
> > > > > -lrte_jobstats
> > > > > -
> > > > > lrte_ip_frag -lrte_gso -lrte_gro -lrte_eventdev -lrte_efd -
> > > > > lrte_distributor -lrte_cryptodev -lrte_compressdev
> > > > > -lrte_cfgfile -
> > > > > lrte_bitratestats -lrte_bbdev -lrte_acl -lrte_timer -lrte_hash
> > > > > -
> > > > > lrte_metrics -lrte_pci -lrte_ethdev -lrte_net -lrte_mbuf
> > > > > -lrte_mempool -
> > > > > lrte_ring -lrte_eal -lrte_kvargs -lrte_cmdline
> > > > > -L/usr/local/lib64 -
> > > > > lrte_kvargs -lrte_eal -lrte_ring -lrte_mempool -lrte_mbuf
> > > > > -lrte_pci
> > > > > -
> > > > > lrte_cryptodev -lrte_net -lrte_cmdline -lrte_ethdev -lrte_hash
> > > > > -lrte_timer
> > > > > -lrte_common_dpaax -lrte_eventdev -lrte_rawdev -lrte_bus_dpaa -
> > > > > lrte_bus_fslmc -lrte_bus_pci -lrte_common_octeontx
> > > > > -lrte_bus_vdev -
> > > > > lrte_meter -lrte_sched -lrte_ip_frag -lz -lrte_mempool_dpaa -
> > > > > lrte_mempool_dpaa2 -lrte_vhost -lrte_security -lrte_kni -lmnl
> > > > > -lmlx4 -
> > > > > libverbs -lmnl -lmlx5 -libverbs -lrte_bus_vmbus
> > > > > -lrte_mempool_octeontx -
> > > > > lpcap -lrte_port -lrte_lpm -lrte_acl -lrte_table -lrte_pipeline
> > > > > -lsze2 -
> > > > > lrte_gso -lIPSec_MB -lIPSec_MB -lrte_common_cpt -lrte_reorder -
> > > > > lrte_compressdev -lrte_pmd_dpaa -lrte_pmd_dpaa2
> > > > > -lrte_pmd_dpaa2_sec
> > > > > -
> > > > > lrte_pmd_octeontx -lrte_bbdev -lrte_bus_ifpga -Wl,--whole-
> > > > > archive -
> > > > > lrte_mempool_bucket -lrte_mempool_ring -lrte_mempool_stack -
> > > > > lrte_pmd_af_packet -lrte_pmd_ark -lrte_pmd_atlantic
> > > > > -lrte_pmd_avf -
> > > > > lrte_pmd_avp -lrte_pmd_axgbe -lrte_pmd_bond -lrte_pmd_bnx2x
> > > > > -lrte_pmd_bnxt
> > > > > -lrte_pmd_cxgbe -lrte_pmd_e1000 -lrte_pmd_ena -lrte_pmd_enetc -
> > > > > lrte_pmd_enic -lrte_pmd_failsafe -lrte_pmd_fm10k -lrte_pmd_i40e
> > > > > -
> > > > > lrte_pmd_ifc -lrte_pmd_ixgbe -lrte_pmd_kmod -lrte_pmd_kni -
> > > > > lrte_pmd_liquidio -lrte_pmd_mlx4 -lrte_pmd_mlx5
> > > > > -lrte_pmd_netvsc -
> > > > > lrte_pmd_nfp -lrte_pmd_null -lrte_pmd_pcap -lrte_pmd_qede
> > > > > -lrte_pmd_ring -
> > > > > lrte_pmd_sfc -lrte_pmd_softnic -lrte_pmd_szedata2 -lrte_pmd_tap
> > > > > -
> > > > > lrte_pmd_thunderx -lrte_pmd_vdev_netvsc -lrte_pmd_vhost
> > > > > -lrte_pmd_virtio -
> > > > > lrte_pmd_vmxnet3 -lrte_pmd_aesni_gcm -lrte_pmd_aesni_mb
> > > > > -lrte_pmd_caam_jr
> > > > > -lrte_pmd_ccp -lrte_pmd_dpaa_sec -lrte_pmd_null_crypto -
> > > > > lrte_pmd_octeontx_crypto -lrte_pmd_openssl
> > > > > -lrte_pmd_crypto_scheduler -
> > > > > lrte_pmd_virtio_crypto -lrte_pmd_octeontx_compress
> > > > > -lrte_pmd_qat -
> > > > > lrte_pmd_zlib -lrte_pmd_dpaa_event -lrte_pmd_dpaa2_event -
> > > > > lrte_pmd_octeontx_event -lrte_pmd_opdl_event
> > > > > -lrte_pmd_skeleton_event -
> > > > > lrte_pmd_sw_event -lrte_pmd_dsw_event -lrte_pmd_bbdev_null -
> > > > > lrte_pmd_skeleton_rawdev -lrte_pmd_dpaa2_cmdif
> > > > > -lrte_pmd_dpaa2_qdma
> > > > > -
> > > > > lrte_pmd_ifpga_rawdev -lrte_pmd_ioat_copy -Wl,--no-whole-
> > > > > archive
> > > > > -Wl,-
> > > > > Bdynamic -Wl,--no-as-needed -pthread -lm -ldl -lnuma -lbsd
> > > > > -lpcap
> > > > > -lcrypto
> > > > > -lcrypto -lz -lcrypto -ldl -pthread -lz
> > > > > 
> > > > > Hi Bruce, I tried with rc3 and a new clone from right now, and
> > > > > get
> > > > > the
> > > > > same results:
> > > > > 
> > > > > $ meson build
> > > > > The Meson build system
> > > > > Version: 0.45.1
> > > > > Source dir: /home/cburdick/dpdk
> > > > > Build dir: /home/cburdick/dpdk/build
> > > > > Build type: native build
> > > > > Project name: DPDK
> > > > > Native C compiler: cc (gcc 7.3.0 "cc (Ubuntu 7.3.0-
> > > > > 27ubuntu1~18.04)
> > > > > 7.3.0")
> > > > > Build machine cpu family: x86_64
> > > > > Build machine cpu: x86_64
> > > > > Library numa found: YES
> > > > > Has header "numaif.h": YES
> > > > > Library bsd found: NO
> > > > > Checking for size of "void *": 8
> > > > > Compiler for C supports argument -Wsign-compare: YES
> > > > > Compiler for C supports argument -Wcast-qual: YES
> > > > > Compiler for C supports argument -Wno-address-of-packed-member: 
> > > > > YES
> > > > > Fetching value of define "__SSE4_2__": 1
> > > > > Fetching value of define "__AES__": 1
> > > > > Fetching value of define "__PCLMUL__": 1
> > > > > Fetching value of define "__AVX__": 1
> > > > > Fetching value of define "__AVX2__": 1
> > > > > Fetching value of define "__AVX512F__":
> > > > > Compiler for C supports argument -Wno-format-truncation: YES
> > > > > Checking for size of "void *": 8
> > > > > Has header "linux/userfaultfd.h": YES
> > > > > Checking for size of "void *": 8
> > > > > Library elf found: NO
> > > > > Library jansson found: NO
> > > > > Program gen-pmdinfo-cfile.sh found: YES
> > > > > (/home/cburdick/dpdk/buildtools/gen-pmdinfo-cfile.sh)
> > > > > Compiler for C supports argument -Wno-format-truncation: YES
> > > > > Library libmusdk found: NO
> > > > > Compiler for C supports argument -Wno-cast-qual: YES
> > > > > Compiler for C supports argument -Wno-pointer-to-int-cast: YES
> > > > > Library z found: NO
> > > > > Compiler for C supports argument -Wno-uninitialized: YES
> > > > > Compiler for C supports argument -Wno-unused-parameter: YES
> > > > > Compiler for C supports argument -Wno-unused-variable: YES
> > > > > Compiler for C supports argument -Wno-misleading-indentation:
> > > > > YES
> > > > > Compiler for C supports argument -Wno-implicit-fallthrough: YES
> > > > > Checking for size of "void *": 8
> > > > > Compiler for C supports argument -Wno-unused-parameter: YES
> > > > > Compiler for C supports argument -Wno-unused-value: YES
> > > > > Compiler for C supports argument -Wno-strict-aliasing: YES
> > > > > Compiler for C supports argument -Wno-format-extra-args: YES
> > > > > Compiler for C supports argument -Wno-unused-variable: YES
> > > > > Compiler for C supports argument -Wno-missing-field-
> > > > > initializers:
> > > > > YES
> > > > > Compiler for C supports argument -Wno-sign-compare: YES
> > > > > Compiler for C supports argument -Wno-unused-value: YES
> > > > > Compiler for C supports argument -Wno-format: YES
> > > > > Compiler for C supports argument -Wno-error=format-security:
> > > > > YES
> > > > > Compiler for C supports argument -Wno-strict-aliasing: YES
> > > > > Compiler for C supports argument -Wno-unused-but-set-variable:
> > > > > YES
> > > > > Compiler for C supports argument -Wno-unused-value: YES
> > > > > Compiler for C supports argument -Wno-unused-but-set-variable:
> > > > > YES
> > > > > Library mnl found: YES
> > > > > Library mlx4 found: YES
> > > > > Library ibverbs found: YES
> > > > > Compiler for C supports argument -Wextra: YES
> > > > > Compiler for C supports argument -std=c11: YES
> > > > > Compiler for C supports argument -Wno-strict-prototypes: YES
> > > > > Compiler for C supports argument -D_BSD_SOURCE: YES
> > > > > Compiler for C supports argument -D_DEFAULT_SOURCE: YES
> > > > > Compiler for C supports argument -D_XOPEN_SOURCE=600: YES
> > > > > Checking whether type "struct mlx4_wqe_lso_seg" has member
> > > > > "mss_hdr_size":
> > > > > YES
> > > > > Configuring mlx4_autoconf.h using configuration
> > > > > Library mnl found: YES
> > > > > Library mlx5 found: YES
> > > > > Library ibverbs found: YES
> > > > > Compiler for C supports argument -Wextra: YES
> > > > > Compiler for C supports argument -std=c11: YES
> > > > > Compiler for C supports argument -Wno-strict-prototypes: YES
> > > > > Compiler for C supports argument -D_BSD_SOURCE: YES
> > > > > Compiler for C supports argument -D_DEFAULT_SOURCE: YES
> > > > > Compiler for C supports argument -D_XOPEN_SOURCE=600: YES
> > > > > Header <infiniband/mlx5dv.h> has symbol
> > > > > "MLX5DV_CQE_RES_FORMAT_CSUM_STRIDX": YES
> > > > > Header <infiniband/mlx5dv.h> has symbol
> > > > > "MLX5DV_CONTEXT_MASK_TUNNEL_OFFLOADS": YES
> > > > > Header <infiniband/mlx5dv.h> has symbol
> > > > > "MLX5DV_CONTEXT_FLAGS_MPW_ALLOWED": YES
> > > > > Header <infiniband/mlx5dv.h> has symbol
> > > > > "MLX5DV_CONTEXT_FLAGS_CQE_128B_COMP": YES
> > > > > Header <infiniband/mlx5dv.h> has symbol
> > > > > "MLX5DV_CQ_INIT_ATTR_FLAGS_CQE_PAD": YES
> > > > > Header <infiniband/mlx5dv.h> has symbol
> > > > > "mlx5dv_create_flow_action_packet_reformat": NO
> > > > > Header <infiniband/verbs.h> has symbol "IBV_FLOW_SPEC_MPLS":
> > > > > YES
> > > > > Header <infiniband/verbs.h> has symbol
> > > > > "IBV_WQ_FLAG_RX_END_PADDING": NO
> > > > > Header <linux/ethtool.h> has symbol
> > > > > "SUPPORTED_40000baseKR4_Full":
> > > > > YES
> > > > > Header <linux/ethtool.h> has symbol
> > > > > "SUPPORTED_40000baseCR4_Full":
> > > > > YES
> > > > > Header <linux/ethtool.h> has symbol
> > > > > "SUPPORTED_40000baseSR4_Full":
> > > > > YES
> > > > > Header <linux/ethtool.h> has symbol
> > > > > "SUPPORTED_40000baseLR4_Full":
> > > > > YES
> > > > > Header <linux/ethtool.h> has symbol
> > > > > "SUPPORTED_56000baseKR4_Full":
> > > > > YES
> > > > > Header <linux/ethtool.h> has symbol
> > > > > "SUPPORTED_56000baseCR4_Full":
> > > > > YES
> > > > > Header <linux/ethtool.h> has symbol
> > > > > "SUPPORTED_56000baseSR4_Full":
> > > > > YES
> > > > > Header <linux/ethtool.h> has symbol
> > > > > "SUPPORTED_56000baseLR4_Full":
> > > > > YES
> > > > > Header <linux/ethtool.h> has symbol
> > > > > "ETHTOOL_LINK_MODE_25000baseCR_Full_BIT": YES
> > > > > Header <linux/ethtool.h> has symbol
> > > > > "ETHTOOL_LINK_MODE_50000baseCR2_Full_BIT": YES
> > > > > Header <linux/ethtool.h> has symbol
> > > > > "ETHTOOL_LINK_MODE_100000baseKR4_Full_BIT": YES
> > > > > Header <linux/if_link.h> has symbol "IFLA_PHYS_SWITCH_ID": YES
> > > > > Header <linux/if_link.h> has symbol "IFLA_PHYS_PORT_NAME": YES
> > > > > Header <linux/if_link.h> has symbol
> > > > > "IFLA_VXLAN_COLLECT_METADATA":
> > > > > YES
> > > > > Header <linux/rtnetlink.h> has symbol "TCA_CHAIN": YES
> > > > > Header <linux/pkt_cls.h> has symbol "TCA_FLOWER_ACT": YES
> > > > > Header <linux/pkt_cls.h> has symbol "TCA_FLOWER_FLAGS": YES
> > > > > Header <linux/pkt_cls.h> has symbol "TCA_FLOWER_KEY_ETH_TYPE":
> > > > > YES
> > > > > Header <linux/pkt_cls.h> has symbol "TCA_FLOWER_KEY_ETH_DST":
> > > > > YES
> > > > > Header <linux/pkt_cls.h> has symbol
> > > > > "TCA_FLOWER_KEY_ETH_DST_MASK":
> > > > > YES
> > > > > Header <linux/pkt_cls.h> has symbol "TCA_FLOWER_KEY_ETH_SRC":
> > > > > YES
> > > > > Header <linux/pkt_cls.h> has symbol
> > > > > "TCA_FLOWER_KEY_ETH_SRC_MASK":
> > > > > YES
> > > > > Header <linux/pkt_cls.h> has symbol "TCA_FLOWER_KEY_IP_PROTO":
> > > > > YES
> > > > > Header <linux/pkt_cls.h> has symbol "TCA_FLOWER_KEY_IPV4_SRC":
> > > > > YES
> > > > > Header <linux/pkt_cls.h> has symbol
> > > > > "TCA_FLOWER_KEY_IPV4_SRC_MASK":
> > > > > YES
> > > > > Header <linux/pkt_cls.h> has symbol "TCA_FLOWER_KEY_IPV4_DST":
> > > > > YES
> > > > > Header <linux/pkt_cls.h> has symbol
> > > > > "TCA_FLOWER_KEY_IPV4_DST_MASK":
> > > > > YES
> > > > > Header <linux/pkt_cls.h> has symbol "TCA_FLOWER_KEY_IPV6_SRC":
> > > > > YES
> > > > > Header <linux/pkt_cls.h> has symbol
> > > > > "TCA_FLOWER_KEY_IPV6_SRC_MASK":
> > > > > YES
> > > > > Header <linux/pkt_cls.h> has symbol "TCA_FLOWER_KEY_IPV6_DST":
> > > > > YES
> > > > > Header <linux/pkt_cls.h> has symbol
> > > > > "TCA_FLOWER_KEY_IPV6_DST_MASK":
> > > > > YES
> > > > > Header <linux/pkt_cls.h> has symbol "TCA_FLOWER_KEY_TCP_SRC":
> > > > > YES
> > > > > Header <linux/pkt_cls.h> has symbol
> > > > > "TCA_FLOWER_KEY_TCP_SRC_MASK":
> > > > > YES
> > > > > Header <linux/pkt_cls.h> has symbol "TCA_FLOWER_KEY_TCP_DST":
> > > > > YES
> > > > > Header <linux/pkt_cls.h> has symbol
> > > > > "TCA_FLOWER_KEY_TCP_DST_MASK":
> > > > > YES
> > > > > Header <linux/pkt_cls.h> has symbol "TCA_FLOWER_KEY_UDP_SRC":
> > > > > YES
> > > > > Header <linux/pkt_cls.h> has symbol
> > > > > "TCA_FLOWER_KEY_UDP_SRC_MASK":
> > > > > YES
> > > > > Header <linux/pkt_cls.h> has symbol "TCA_FLOWER_KEY_UDP_DST":
> > > > > YES
> > > > > Header <linux/pkt_cls.h> has symbol
> > > > > "TCA_FLOWER_KEY_UDP_DST_MASK":
> > > > > YES
> > > > > Header <linux/pkt_cls.h> has symbol "TCA_FLOWER_KEY_VLAN_ID":
> > > > > YES
> > > > > Header <linux/pkt_cls.h> has symbol "TCA_FLOWER_KEY_VLAN_PRIO":
> > > > > YES
> > > > > Header <linux/pkt_cls.h> has symbol
> > > > > "TCA_FLOWER_KEY_VLAN_ETH_TYPE":
> > > > > YES
> > > > > Header <linux/pkt_cls.h> has symbol "TCA_FLOWER_KEY_TCP_FLAGS":
> > > > > YES
> > > > > Header <linux/pkt_cls.h> has symbol
> > > > > "TCA_FLOWER_KEY_TCP_FLAGS_MASK": YES
> > > > > Header <linux/pkt_cls.h> has symbol "TC_ACT_GOTO_CHAIN": YES
> > > > > Header <linux/tc_act/tc_vlan.h> has symbol
> > > > > "TCA_VLAN_PUSH_VLAN_PRIORITY":
> > > > > YES
> > > > > Header <linux/pkt_cls.h> has symbol
> > > > > "TCA_FLOWER_KEY_ENC_KEY_ID":
> > > > > YES
> > > > > Header <linux/pkt_cls.h> has symbol
> > > > > "TCA_FLOWER_KEY_ENC_IPV4_SRC":
> > > > > YES
> > > > > Header <linux/pkt_cls.h> has symbol
> > > > > "TCA_FLOWER_KEY_ENC_IPV4_SRC_MASK":
> > > > > YES
> > > > > Header <linux/pkt_cls.h> has symbol
> > > > > "TCA_FLOWER_KEY_ENC_IPV4_DST":
> > > > > YES
> > > > > Header <linux/pkt_cls.h> has symbol
> > > > > "TCA_FLOWER_KEY_ENC_IPV4_DST_MASK":
> > > > > YES
> > > > > Header <linux/pkt_cls.h> has symbol
> > > > > "TCA_FLOWER_KEY_ENC_IPV6_SRC":
> > > > > YES
> > > > > Header <linux/pkt_cls.h> has symbol
> > > > > "TCA_FLOWER_KEY_ENC_IPV6_SRC_MASK":
> > > > > YES
> > > > > Header <linux/pkt_cls.h> has symbol
> > > > > "TCA_FLOWER_KEY_ENC_IPV6_DST":
> > > > > YES
> > > > > Header <linux/pkt_cls.h> has symbol
> > > > > "TCA_FLOWER_KEY_ENC_IPV6_DST_MASK":
> > > > > YES
> > > > > Header <linux/pkt_cls.h> has symbol
> > > > > "TCA_FLOWER_KEY_ENC_UDP_SRC_PORT": YES
> > > > > Header <linux/pkt_cls.h> has symbol
> > > > > "TCA_FLOWER_KEY_ENC_UDP_SRC_PORT_MASK": YES
> > > > > Header <linux/pkt_cls.h> has symbol
> > > > > "TCA_FLOWER_KEY_ENC_UDP_DST_PORT": YES
> > > > > Header <linux/pkt_cls.h> has symbol
> > > > > "TCA_FLOWER_KEY_ENC_UDP_DST_PORT_MASK": YES
> > > > > Header <linux/tc_act/tc_tunnel_key.h> has symbol
> > > > > "TCA_ACT_TUNNEL_KEY": YES
> > > > > Header <linux/tc_act/tc_tunnel_key.h> has symbol
> > > > > "TCA_TUNNEL_KEY_ENC_DST_PORT": YES
> > > > > Header <linux/tc_act/tc_tunnel_key.h> has symbol
> > > > > "TCA_TUNNEL_KEY_NO_CSUM":
> > > > > YES
> > > > > Header <linux/tc_act/tc_pedit.h> has symbol
> > > > > "TCA_PEDIT_KEY_EX_HDR_TYPE_UDP": YES
> > > > > Header <rdma/rdma_netlink.h> has symbol "RDMA_NL_NLDEV": YES
> > > > > Header <rdma/rdma_netlink.h> has symbol "RDMA_NLDEV_CMD_GET":
> > > > > YES
> > > > > Header <rdma/rdma_netlink.h> has symbol
> > > > > "RDMA_NLDEV_CMD_PORT_GET":
> > > > > YES
> > > > > Header <rdma/rdma_netlink.h> has symbol
> > > > > "RDMA_NLDEV_ATTR_DEV_INDEX": YES
> > > > > Header <rdma/rdma_netlink.h> has symbol
> > > > > "RDMA_NLDEV_ATTR_DEV_NAME":
> > > > > YES
> > > > > Header <rdma/rdma_netlink.h> has symbol
> > > > > "RDMA_NLDEV_ATTR_PORT_INDEX": YES
> > > > > Header <rdma/rdma_netlink.h> has symbol
> > > > > "RDMA_NLDEV_ATTR_NDEV_INDEX": NO
> > > > > Checking whether type "struct mlx5dv_sw_parsing_caps" has
> > > > > member
> > > > > "sw_parsing_offloads": YES
> > > > > Checking whether type "struct ibv_counter_set_init_attr" has
> > > > > member
> > > > > "counter_set_id": YES
> > > > > Checking whether type "struct ibv_counters_init_attr" has
> > > > > member
> > > > > "comp_mask": NO
> > > > > Configuring mlx5_autoconf.h using configuration
> > > > > Library libmusdk found: NO
> > > > > Library libmusdk found: NO
> > > > > Library pcap found: NO
> > > > > Compiler for C supports argument -Wno-unused-parameter: YES
> > > > > Compiler for C supports argument -Wno-sign-compare: YES
> > > > > Compiler for C supports argument -Wno-missing-prototypes: YES
> > > > > Compiler for C supports argument -Wno-cast-qual: YES
> > > > > Compiler for C supports argument -Wno-unused-function: YES
> > > > > Compiler for C supports argument -Wno-unused-variable: YES
> > > > > Compiler for C supports argument -Wno-strict-aliasing: YES
> > > > > Compiler for C supports argument -Wno-missing-prototypes: YES
> > > > > Compiler for C supports argument -Wno-unused-value: YES
> > > > > Compiler for C supports argument -Wno-format-nonliteral: YES
> > > > > Compiler for C supports argument -Wno-shift-negative-value: YES
> > > > > Compiler for C supports argument -Wno-unused-but-set-variable:
> > > > > YES
> > > > > Compiler for C supports argument -Wno-missing-declarations: YES
> > > > > Compiler for C supports argument -Wno-maybe-uninitialized: YES
> > > > > Compiler for C supports argument -Wno-strict-prototypes: YES
> > > > > Compiler for C supports argument -Wno-shift-negative-value: YES
> > > > > Compiler for C supports argument -Wno-implicit-fallthrough: YES
> > > > > Compiler for C supports argument -Wno-format-extra-args: YES
> > > > > Compiler for C supports argument -Wno-visibility: YES
> > > > > Compiler for C supports argument -Wno-empty-body: YES
> > > > > Compiler for C supports argument -Wno-invalid-source-encoding:
> > > > > YES
> > > > > Compiler for C supports argument -Wno-sometimes-uninitialized:
> > > > > YES
> > > > > Compiler for C supports argument -Wno-pointer-bool-conversion:
> > > > > YES
> > > > > Checking for size of "void *": 8
> > > > > Compiler for C supports argument -Wno-strict-aliasing: YES
> > > > > Compiler for C supports argument -Wextra: YES
> > > > > Compiler for C supports argument -Wdisabled-optimization: YES
> > > > > Compiler for C supports argument -Waggregate-return: YES
> > > > > Compiler for C supports argument -Wnested-externs: YES
> > > > > Compiler for C supports argument -Wbad-function-cast: YES
> > > > > Compiler for C supports argument -Wno-sign-compare: YES
> > > > > Compiler for C supports argument -Wno-unused-parameter: YES
> > > > > Compiler for C supports argument -Wno-unused-variable: YES
> > > > > Compiler for C supports argument -Wno-empty-body: YES
> > > > > Compiler for C supports argument -Wno-unused-but-set-variable:
> > > > > YES
> > > > > Library sze2 found: NO
> > > > > Header <linux/pkt_cls.h> has symbol "TCA_FLOWER_UNSPEC": YES
> > > > > Header <linux/pkt_cls.h> has symbol "TCA_FLOWER_KEY_VLAN_PRIO":
> > > > > YES
> > > > > Header <linux/pkt_cls.h> has symbol "TCA_BPF_UNSPEC": YES
> > > > > Header <linux/pkt_cls.h> has symbol "TCA_BPF_FD": YES
> > > > > Header <linux/tc_act/tc_bpf.h> has symbol "TCA_ACT_BPF_UNSPEC":
> > > > > YES
> > > > > Header <linux/tc_act/tc_bpf.h> has symbol "TCA_ACT_BPF_FD": YES
> > > > > Configuring tap_autoconf.h using configuration
> > > > > Compiler for C supports argument -fno-prefetch-loop-arrays: YES
> > > > > Compiler for C supports argument -Wno-maybe-uninitialized: YES
> > > > > Compiler for C supports argument -Wall: YES
> > > > > Compiler for C supports argument -Wextra: YES
> > > > > Compiler for C supports argument -D_BSD_SOURCE: YES
> > > > > Compiler for C supports argument -D_DEFAULT_SOURCE: YES
> > > > > Compiler for C supports argument -D_XOPEN_SOURCE=600: YES
> > > > > Compiler for C supports argument -Wno-unused-parameter: YES
> > > > > Compiler for C supports argument -Wno-unused-value: YES
> > > > > Compiler for C supports argument -Wno-strict-aliasing: YES
> > > > > Compiler for C supports argument -Wno-format-extra-args: YES
> > > > > Library IPSec_MB found: NO
> > > > > Library IPSec_MB found: NO
> > > > > Found pkg-config: /usr/bin/pkg-config (0.29.1)
> > > > > Native dependency libcrypto found: YES 1.1.0g
> > > > > Library libsso_kasumi found: NO
> > > > > Library libmusdk found: NO
> > > > > Dependency libcrypto found: YES (cached)
> > > > > Dependency libcrypto found: YES (cached)
> > > > > Library libsso_zuc found: NO
> > > > > Dependency libisal found: NO
> > > > > Dependency zlib found: NO
> > > > > Compiler for C supports argument -Wno-sign-compare: YES
> > > > > Compiler for C supports argument -Wno-unused-value: YES
> > > > > Compiler for C supports argument -Wno-format: YES
> > > > > Compiler for C supports argument -Wno-error=format-security:
> > > > > YES
> > > > > Compiler for C supports argument -Wno-strict-aliasing: YES
> > > > > Compiler for C supports argument -Wno-unused-but-set-variable:
> > > > > YES
> > > > > Library execinfo found: NO
> > > > > Compiler for C supports argument -Wno-format-truncation: YES
> > > > > Dependency zlib found: NO
> > > > > Library execinfo found: NO
> > > > > Program doxygen found: NO
> > > > > Program sphinx-build found: NO
> > > > > kernel/linux/kni/meson.build:16: WARNING: Passed invalid
> > > > > keyword
> > > > > argument
> > > > > "console".
> > > > > WARNING: This will become a hard error in the future.
> > > > > WARNING: Unknown keyword arguments in target rte_kni: console
> > > > > Configuring rte_build_config.h using configuration
> > > > > Program buildtools/symlink-drivers-solibs.sh found: YES
> > > > > (/bin/sh
> > > > > /home/cburdick/dpdk/buildtools/symlink-drivers-solibs.sh)
> > > > > Message:
> > > > > =================
> > > > > Libraries Enabled
> > > > > =================
> > > > > 
> > > > > libs:
> > > > > \tcompat, cmdline, kvargs, eal, ring, mempool, mbuf, net,
> > > > > \tethdev, pci, metrics, hash, timer, acl, bbdev, bitratestats,
> > > > > \tcfgfile, compressdev, cryptodev, distributor, efd, eventdev,
> > > > > gro,
> > > > > gso,
> > > > > \tip_frag, jobstats, kni, latencystats, lpm, member, meter,
> > > > > power,
> > > > > \tpdump, rawdev, reorder, sched, security, vhost, port, table,
> > > > > \tpipeline, flow_classify, bpf,
> > > > > 
> > > > > Build targets in project: 411
> > > > > Found ninja-1.8.2 at /usr/bin/ninja
> > > > > [cburdick@dev01 ~/dpdk] (master)
> > > > > $ cd build
> > > > > [cburdick@dev01 ~/dpdk/build] (master)
> > > > > $ ninja
> > > > > [1428/1431] Generating igb_uio with a custom command.
> > > > > make: Entering directory '/usr/src/linux-headers-4.15.0-20-
> > > > > generic'
> > > > > Makefile:976: "Cannot use CONFIG_STACK_VALIDATION=y, please
> > > > > install
> > > > > libelf-dev, libelf-devel or elfutils-libelf-devel"
> > > > >   CC
> > > > > [M]  /home/cburdick/dpdk/build/kernel/linux/igb_uio/igb_uio.o
> > > > >   Building modules, stage 2.
> > > > >   MODPOST 1 modules
> > > > >  
> > > > > CC      /home/cburdick/dpdk/build/kernel/linux/igb_uio/igb_uio.
> > > > > mod.
> > > > > o
> > > > >   LD
> > > > > [M]  /home/cburdick/dpdk/build/kernel/linux/igb_uio/igb_uio.ko
> > > > > make: Leaving directory '/usr/src/linux-headers-4.15.0-20-
> > > > > generic'
> > > > > [1431/1431] Generating rte_kni with a custom command.
> > > > > make: Entering directory '/usr/src/linux-headers-4.15.0-20-
> > > > > generic'
> > > > > Makefile:976: "Cannot use CONFIG_STACK_VALIDATION=y, please
> > > > > install
> > > > > libelf-dev, libelf-devel or elfutils-libelf-devel"
> > > > >   CC [M]  /home/cburdick/dpdk/build/kernel/linux/kni/kni_net.o
> > > > >   CC [M]  /home/cburdick/dpdk/build/kernel/linux/kni/kni_misc.o
> > > > >   CC
> > > > > [M]  /home/cburdick/dpdk/build/kernel/linux/kni/kni_ethtool.o
> > > > >   CC [M]
> > > > > /home/cburdick/dpdk/build/kernel/linux/kni/ethtool/ixgbe/ixgbe_
> > > > > etht
> > > > > ool.o
> > > > >   CC [M]
> > > > > /home/cburdick/dpdk/build/kernel/linux/kni/ethtool/ixgbe/ixgbe_
> > > > > 8259
> > > > > 9.o
> > > > >   CC [M]
> > > > > /home/cburdick/dpdk/build/kernel/linux/kni/ethtool/ixgbe/ixgbe_
> > > > > api.
> > > > > o
> > > > >   CC [M]
> > > > > /home/cburdick/dpdk/build/kernel/linux/kni/ethtool/ixgbe/ixgbe_
> > > > > x540
> > > > > .o
> > > > >   CC [M]
> > > > > /home/cburdick/dpdk/build/kernel/linux/kni/ethtool/ixgbe/ixgbe_
> > > > > comm
> > > > > on.o
> > > > >   CC [M]
> > > > > /home/cburdick/dpdk/build/kernel/linux/kni/ethtool/ixgbe/ixgbe_
> > > > > phy.
> > > > > o
> > > > >   CC [M]
> > > > > /home/cburdick/dpdk/build/kernel/linux/kni/ethtool/ixgbe/ixgbe_
> > > > > 8259
> > > > > 8.o
> > > > >   CC [M]
> > > > > /home/cburdick/dpdk/build/kernel/linux/kni/ethtool/ixgbe/ixgbe_
> > > > > main
> > > > > .o
> > > > >   CC [M]
> > > > > /home/cburdick/dpdk/build/kernel/linux/kni/ethtool/ixgbe/kcompa
> > > > > t.o
> > > > >   CC [M]
> > > > > /home/cburdick/dpdk/build/kernel/linux/kni/ethtool/igb/e1000_82
> > > > > 575.
> > > > > o
> > > > >   CC [M]
> > > > > /home/cburdick/dpdk/build/kernel/linux/kni/ethtool/igb/e1000_i2
> > > > > 10.o
> > > > >   CC [M]
> > > > > /home/cburdick/dpdk/build/kernel/linux/kni/ethtool/igb/e1000_mb
> > > > > x.o
> > > > >   CC [M]
> > > > > /home/cburdick/dpdk/build/kernel/linux/kni/ethtool/igb/e1000_ap
> > > > > i.o
> > > > >   CC [M]
> > > > > /home/cburdick/dpdk/build/kernel/linux/kni/ethtool/igb/igb_main
> > > > > .o
> > > > >   CC [M]
> > > > > /home/cburdick/dpdk/build/kernel/linux/kni/ethtool/igb/igb_vmdq
> > > > > .o
> > > > >   CC [M]
> > > > > /home/cburdick/dpdk/build/kernel/linux/kni/ethtool/igb/e1000_ma
> > > > > nage
> > > > > .o
> > > > >   CC [M]
> > > > > /home/cburdick/dpdk/build/kernel/linux/kni/ethtool/igb/igb_etht
> > > > > ool.
> > > > > o
> > > > >   CC [M]
> > > > > /home/cburdick/dpdk/build/kernel/linux/kni/ethtool/igb/igb_para
> > > > > m.o
> > > > >   CC [M]
> > > > > /home/cburdick/dpdk/build/kernel/linux/kni/ethtool/igb/e1000_ma
> > > > > c.o
> > > > >   CC [M]
> > > > > /home/cburdick/dpdk/build/kernel/linux/kni/ethtool/igb/e1000_ph
> > > > > y.o
> > > > >   CC [M]
> > > > > /home/cburdick/dpdk/build/kernel/linux/kni/ethtool/igb/e1000_nv
> > > > > m.o
> > > > >   LD [M]  /home/cburdick/dpdk/build/kernel/linux/kni/rte_kni.o
> > > > >   Building modules, stage 2.
> > > > >   MODPOST 1 modules
> > > > >  
> > > > > CC      /home/cburdick/dpdk/build/kernel/linux/kni/rte_kni.mod.
> > > > > o
> > > > >   LD [M]  /home/cburdick/dpdk/build/kernel/linux/kni/rte_kni.ko
> > > > > make: Leaving directory '/usr/src/linux-headers-4.15.0-20-
> > > > > generic'
> > > > > [cburdick@dev01 ~/dpdk/build] (master)
> > > > > $ PKG_CONFIG_PATH=meson-private/ pkg-config --libs --static
> > > > > libdpdk|grep
> > > > > mlx
> > > > > -L/usr/local/lib/x86_64-linux-gnu -lrte_flow_classify
> > > > > -lrte_eventdev -
> > > > > lrte_ip_frag -lrte_power -lrte_hash -lrte_pdump -lrte_pipeline
> > > > > -lrte_table
> > > > > -lrte_mbuf -lrte_bbdev -lrte_bpf -lrte_vhost -lrte_metrics
> > > > > -lrte_mempool -
> > > > > lrte_jobstats -lrte_reorder -lrte_net -lrte_security -lrte_eal
> > > > > -lrte_ring
> > > > > -lrte_ethdev -lrte_compressdev -lrte_rawdev -lrte_kvargs
> > > > > -lrte_pci
> > > > > -
> > > > > lrte_cfgfile -lrte_gro -lrte_gso -lrte_cryptodev
> > > > > -lrte_latencystats
> > > > > -
> > > > > lrte_sched -lrte_efd -lrte_distributor -lrte_acl -lrte_member -
> > > > > lrte_cmdline -lrte_lpm -lrte_meter -lrte_kni -lrte_bitratestats
> > > > > -
> > > > > lrte_timer -lrte_port -lrte_mempool_bucket
> > > > > -lrte_pmd_vdev_netvsc -
> > > > > lrte_pmd_ark -lrte_pmd_failsafe -lrte_pmd_netvsc
> > > > > -lrte_pmd_null_crypto -
> > > > > lrte_bus_ifpga -lrte_common_dpaax -lrte_pmd_ixgbe
> > > > > -lrte_mempool_ring -
> > > > > lrte_pmd_kni -lrte_pmd_vmxnet3 -lrte_pmd_mlx4 -lrte_pmd_virtio
> > > > > -Wl,--no-
> > > > > as-needed -lrte_mempool_dpaa -lrte_pmd_ena -lrte_bus_fslmc
> > > > > -lrte_pmd_avf -
> > > > > lrte_pmd_dpaa2_sec -lrte_common_octeontx
> > > > > -lrte_pmd_skeleton_rawdev
> > > > > -
> > > > > lrte_pmd_crypto_scheduler -lrte_pmd_dpaa2_qdma -lrte_pmd_vhost
> > > > > -ldl
> > > > > -
> > > > > lrte_bus_dpaa -lrte_pmd_fm10k -lrte_pmd_bnxt -lrte_pmd_qat
> > > > > -lrte_pmd_bond
> > > > > -lrte_pmd_axgbe -lrte_pmd_dpaa2 -lrte_pmd_skeleton_event -
> > > > > lrte_pmd_dpaa_event -lrte_mempool_stack -pthread -lrte_pmd_ccp
> > > > > -
> > > > > lrte_pmd_octeontx_compress -lrte_pmd_sw_event
> > > > > -lrte_mempool_octeontx -Wl,-
> > > > > Bdynamic -lrte_pmd_dpaa_sec -lrte_pmd_atlantic
> > > > > -lrte_pmd_octeontx_event -
> > > > > lrte_pmd_avp -lrte_bus_pci -lrte_pmd_dpaa2_cmdif -lrte_pmd_mlx5
> > > > > -
> > > > > lrte_pmd_opdl_event -lrte_pmd_tap -lrte_pmd_caam_jr
> > > > > -lrte_pmd_sfc
> > > > > -lcrypto
> > > > > -lrte_pmd_enetc -lrte_mempool_dpaa2 -lrte_pmd_dpaa2_event
> > > > > -lrte_pmd_ifc -
> > > > > lrte_pmd_liquidio -lrte_pmd_cxgbe -lm -lrte_pmd_enic
> > > > > -lrte_bus_vdev
> > > > > -
> > > > > lrte_pmd_e1000 -lrte_pmd_softnic -lrte_pmd_ifpga_rawdev
> > > > > -lrte_bus_vmbus -
> > > > > lrte_pmd_octeontx_crypto -lrte_pmd_null -lnuma -lrte_common_cpt
> > > > > -
> > > > > lrte_pmd_nfp -lrte_pmd_qede -lrte_pmd_i40e -lrte_pmd_dpaa -Wl,
> > > > > --whole-
> > > > > archive -lrte_pmd_bbdev_null -lrte_pmd_af_packet
> > > > > -lrte_pmd_thunderx
> > > > > -
> > > > > lrte_pmd_openssl -lrte_pmd_octeontx -lrte_pmd_dsw_event -Wl,
> > > > > --no-
> > > > > whole-
> > > > > archive -lrte_pmd_ring -lrte_pmd_virtio_crypto
> > > > 
> > > > That is strange. Can you try one last thing - can you update
> > > > meson
> > > > with "pip3 install --upgrade meson" and see if that makes any
> > > > difference? [If you are using your distro's meson from /usr/bin
> > > > right
> > > > now, you'll probably also need to run "hash meson" afterwards
> > > > too].
> > > > Perhaps we have a hidden dependency on later meson versions or
> > > > something like that.
> > > > 
> > > > /Bruce
> > > 
> > > We do - I can reproduce the same issue with 0.45.1, while normally
> > > I
> > > run 0.47.2. Should we bump the minimum version? Or simply document
> > > it?
> > > 
> > 
> > Bumping the minimum version would be really nice generally for DPDK,
> > but I
> > don't think this is the point in the release cycle to do so. I need
> > to try
> > and track down why this is broken with older mesons - most version
> > specific
> > things are harmless, and I'd like to keep it that way! 
> > 
> > If we can't fix this in rc4, then document, I suggest. That way we
> > don't
> > require absolutely everyone to use bleeding-edge meson.
> > 
> > /Bruce
> 
> I don't think it's anything we do, it's a feature Meson gained in 0.45:
> 
> "libraries: a list of built libraries (usually results of
> shared_library) that the user needs to link against. Arbitrary strings
> can also be provided and they will be added into the Libs field. Since
> 0.45.0 dependencies of built libraries will be automatically added to
> Libs.private field. If a dependency is provided by pkg-config then it
> will be added in Requires.private instead. Other type of dependency
> objects can also be passed and will result in their link_args and
> compile_args to be added to Libs and Cflags fields.
> 
> libraries_private: list of built libraries or strings to put in the
> Libs.private field. Since 0.45.0 it can also contain dependency
> objects, their link_args will be added to Libs.private."
> 
> https://mesonbuild.com/Pkgconfig-module.html
> 
> We could do all of that manually, but IMHO it's fine to document and
> then bump the minimum version for 19.02. I'll send a patch to update
> the doc, let me know if you prefer another solution.
> 
Ok, sounds reasonable.

Thanks,
/Bruce