[PATCH 0/2] add includes to help when editing in Eclipse

[PATCH 0/2] add includes to help when editing in Eclipse

[Bruce Richardson]

These two small patches add in some additional header includes to 3 DPDK
files, in order to improve the experience of anyone who, like me,
sometimes uses eclipse-cdt as an editor for working with DPDK code.
The C indexer in eclipse seems easily confused when missing some of
our macro defintions, so we can reduce that confusion by ensuring
that we include all needed headers to get those definitions.

Bruce Richardson (2):
  examples/l3fwd: add include for macro definition
  common/cnxk: add include for macro definition

 drivers/common/cnxk/roc_io.h         | 2 ++
 examples/l3fwd/l3fwd_em.h            | 2 ++
 examples/l3fwd/l3fwd_em_sequential.h | 2 ++
 3 files changed, 6 insertions(+)

--
2.34.1

[PATCH 1/2] examples/l3fwd: add include for macro definition

[Bruce Richardson]

The header files "l3fwd_em.h" and "l3fwd_em_sequential.h" use the
"__rte_always_inline" macro but don't directly include "rte_common.h" to
get the definition of it. This inclusion is not necessary for
compilation, but the lack of it can confuse some indexers - such as
those in eclipse, which reports the lines:

"static __rte_always_inline uint16_t"

as possible definitions of a variable called "uint16_t". This confusion
leads to uint16_t being flagged as an unknown type in all other parts of
the project being indexed, e.g. across all of DPDK code.

Adding in the include of rte_common.h makes it clear to the indexer that
those lines are  part of a function definition, and that allows eclipse
to correctly recognise uint16_t as a type from stdint.h

Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
---
 examples/l3fwd/l3fwd_em.h            | 2 ++
 examples/l3fwd/l3fwd_em_sequential.h | 2 ++
 2 files changed, 4 insertions(+)

diff --git a/examples/l3fwd/l3fwd_em.h b/examples/l3fwd/l3fwd_em.h
index 11bd951858..fe2ee59f6a 100644
--- a/examples/l3fwd/l3fwd_em.h
+++ b/examples/l3fwd/l3fwd_em.h
@@ -5,6 +5,8 @@
 #ifndef __L3FWD_EM_H__
 #define __L3FWD_EM_H__
 
+#include <rte_common.h>
+
 static __rte_always_inline uint16_t
 l3fwd_em_handle_ipv4(struct rte_mbuf *m, uint16_t portid,
 		     struct rte_ether_hdr *eth_hdr, struct lcore_conf *qconf)
diff --git a/examples/l3fwd/l3fwd_em_sequential.h b/examples/l3fwd/l3fwd_em_sequential.h
index f426c508ef..d2f75edb8a 100644
--- a/examples/l3fwd/l3fwd_em_sequential.h
+++ b/examples/l3fwd/l3fwd_em_sequential.h
@@ -5,6 +5,8 @@
 #ifndef __L3FWD_EM_SEQUENTIAL_H__
 #define __L3FWD_EM_SEQUENTIAL_H__
 
+#include <rte_common.h>
+
 /**
  * @file
  * This is an optional implementation of packet classification in Exact-Match
-- 
2.34.1

[PATCH 2/2] common/cnxk: add include for macro definition

[Bruce Richardson]

The header file "roc_io.h" uses the "__plt_always_inline" macro but
don't include "roc_platform.h" to get the definition of it. This
inclusion is not necessary for compilation, but the lack of it can
confuse some indexers - such as those in eclipse, which reports the
lines:

"static __plt_always_inline uint64_t"

as possible definitions of a variable called "uint64_t". This confusion
leads to uint64_t being flagged as an unknown type in all other parts of
the project being indexed, e.g. across all of DPDK code.

Adding in the include of rte_common.h makes it clear to the indexer that
those lines are  part of a function definition, and that allows eclipse
to correctly recognise uint64_t as a type from stdint.h

Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
---
 drivers/common/cnxk/roc_io.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/common/cnxk/roc_io.h b/drivers/common/cnxk/roc_io.h
index 62e98d9d00..9d73e263f7 100644
--- a/drivers/common/cnxk/roc_io.h
+++ b/drivers/common/cnxk/roc_io.h
@@ -5,6 +5,8 @@
 #ifndef _ROC_IO_H_
 #define _ROC_IO_H_
 
+#include "roc_platform.h" /* for __plt_always_inline macro */
+
 #define ROC_LMT_BASE_ID_GET(lmt_addr, lmt_id)                                  \
 	do {                                                                   \
 		/* 32 Lines per core */                                        \
-- 
2.34.1

Re: [PATCH 2/2] common/cnxk: add include for macro definition

[Thomas Monjalon]

14/06/2022 14:29, Bruce Richardson:
> The header file "roc_io.h" uses the "__plt_always_inline" macro but
> don't include "roc_platform.h" to get the definition of it. This
> inclusion is not necessary for compilation, but the lack of it can
> confuse some indexers - such as those in eclipse, which reports the
> lines:
> 
> "static __plt_always_inline uint64_t"
> 
> as possible definitions of a variable called "uint64_t". This confusion
> leads to uint64_t being flagged as an unknown type in all other parts of
> the project being indexed, e.g. across all of DPDK code.
> 
> Adding in the include of rte_common.h makes it clear to the indexer that
> those lines are  part of a function definition, and that allows eclipse
> to correctly recognise uint64_t as a type from stdint.h

It is not rte_common.h
Looks like a copy past of the first patch.

Re: [PATCH 2/2] common/cnxk: add include for macro definition

[Bruce Richardson]

On Wed, Jun 15, 2022 at 09:06:26AM +0200, Thomas Monjalon wrote:
> 14/06/2022 14:29, Bruce Richardson:
> > The header file "roc_io.h" uses the "__plt_always_inline" macro but
> > don't include "roc_platform.h" to get the definition of it. This
> > inclusion is not necessary for compilation, but the lack of it can
> > confuse some indexers - such as those in eclipse, which reports the
> > lines:
> > 
> > "static __plt_always_inline uint64_t"
> > 
> > as possible definitions of a variable called "uint64_t". This confusion
> > leads to uint64_t being flagged as an unknown type in all other parts of
> > the project being indexed, e.g. across all of DPDK code.
> > 
> > Adding in the include of rte_common.h makes it clear to the indexer that
> > those lines are  part of a function definition, and that allows eclipse
> > to correctly recognise uint64_t as a type from stdint.h
> 
> It is not rte_common.h
> Looks like a copy past of the first patch.
> 
Yes, it's a copy paste error. I got most instances replaced but missed one
(or at least I don't see a second miss).

[PATCH v2 0/2] add includes to help when editing in Eclipse

[Bruce Richardson]

These two small patches add in some additional header includes to 3 DPDK
files, in order to improve the experience of anyone who, like me,
sometimes uses eclipse-cdt as an editor for working with DPDK code.
The C indexer in eclipse seems easily confused when missing some of
our macro definitions, so we can reduce that confusion by ensuring
that we include all needed headers to get those definitions.

V2: fix copy-paste error

Bruce Richardson (2):
  examples/l3fwd: add include for macro definition
  common/cnxk: add include for macro definition

 drivers/common/cnxk/roc_io.h         | 2 ++
 examples/l3fwd/l3fwd_em.h            | 2 ++
 examples/l3fwd/l3fwd_em_sequential.h | 2 ++
 3 files changed, 6 insertions(+)

--
2.34.1

[PATCH v2 1/2] examples/l3fwd: add include for macro definition

[Bruce Richardson]

The header files "l3fwd_em.h" and "l3fwd_em_sequential.h" use the
"__rte_always_inline" macro but don't directly include "rte_common.h" to
get the definition of it. This inclusion is not necessary for
compilation, but the lack of it can confuse some indexers - such as
those in eclipse, which reports the lines:

"static __rte_always_inline uint16_t"

as possible definitions of a variable called "uint16_t". This confusion
leads to uint16_t being flagged as an unknown type in all other parts of
the project being indexed, e.g. across all of DPDK code.

Adding in the include of rte_common.h makes it clear to the indexer that
those lines are  part of a function definition, and that allows eclipse
to correctly recognise uint16_t as a type from stdint.h

Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
---
 examples/l3fwd/l3fwd_em.h            | 2 ++
 examples/l3fwd/l3fwd_em_sequential.h | 2 ++
 2 files changed, 4 insertions(+)

diff --git a/examples/l3fwd/l3fwd_em.h b/examples/l3fwd/l3fwd_em.h
index 11bd951858..fe2ee59f6a 100644
--- a/examples/l3fwd/l3fwd_em.h
+++ b/examples/l3fwd/l3fwd_em.h
@@ -5,6 +5,8 @@
 #ifndef __L3FWD_EM_H__
 #define __L3FWD_EM_H__
 
+#include <rte_common.h>
+
 static __rte_always_inline uint16_t
 l3fwd_em_handle_ipv4(struct rte_mbuf *m, uint16_t portid,
 		     struct rte_ether_hdr *eth_hdr, struct lcore_conf *qconf)
diff --git a/examples/l3fwd/l3fwd_em_sequential.h b/examples/l3fwd/l3fwd_em_sequential.h
index f426c508ef..d2f75edb8a 100644
--- a/examples/l3fwd/l3fwd_em_sequential.h
+++ b/examples/l3fwd/l3fwd_em_sequential.h
@@ -5,6 +5,8 @@
 #ifndef __L3FWD_EM_SEQUENTIAL_H__
 #define __L3FWD_EM_SEQUENTIAL_H__
 
+#include <rte_common.h>
+
 /**
  * @file
  * This is an optional implementation of packet classification in Exact-Match
-- 
2.34.1

Re: [PATCH v2 1/2] examples/l3fwd: add include for macro definition

[Thomas Monjalon]

15/06/2022 19:10, Bruce Richardson:
> The header files "l3fwd_em.h" and "l3fwd_em_sequential.h" use the
> "__rte_always_inline" macro but don't directly include "rte_common.h" to
> get the definition of it. This inclusion is not necessary for
> compilation, but the lack of it can confuse some indexers - such as
> those in eclipse, which reports the lines:
> 
> "static __rte_always_inline uint16_t"
> 
> as possible definitions of a variable called "uint16_t". This confusion
> leads to uint16_t being flagged as an unknown type in all other parts of
> the project being indexed, e.g. across all of DPDK code.
> 
> Adding in the include of rte_common.h makes it clear to the indexer that
> those lines are  part of a function definition, and that allows eclipse
> to correctly recognise uint16_t as a type from stdint.h
> 
> Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>

Applied, thanks.

[PATCH v2 2/2] common/cnxk: add include for macro definition

[Bruce Richardson]

The header file "roc_io.h" uses the "__plt_always_inline" macro but
don't include "roc_platform.h" to get the definition of it. This
inclusion is not necessary for compilation, but the lack of it can
confuse some indexers - such as those in eclipse, which reports the
lines:

"static __plt_always_inline uint64_t"

as possible definitions of a variable called "uint64_t". This confusion
leads to uint64_t being flagged as an unknown type in all other parts of
the project being indexed, e.g. across all of DPDK code.

Adding in the include of roc_platform.h makes it clear to the indexer
that those lines are  part of a function definition, and that allows
eclipse to correctly recognise uint64_t as a type from stdint.h

Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
---
V2: fix copy-paste error, where header name replacement was missed
---
 drivers/common/cnxk/roc_io.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/common/cnxk/roc_io.h b/drivers/common/cnxk/roc_io.h
index 62e98d9d00..9d73e263f7 100644
--- a/drivers/common/cnxk/roc_io.h
+++ b/drivers/common/cnxk/roc_io.h
@@ -5,6 +5,8 @@
 #ifndef _ROC_IO_H_
 #define _ROC_IO_H_

+#include "roc_platform.h" /* for __plt_always_inline macro */
+
 #define ROC_LMT_BASE_ID_GET(lmt_addr, lmt_id)                                  \
 	do {                                                                   \
 		/* 32 Lines per core */                                        \
--
2.34.1

Re: [PATCH v2 2/2] common/cnxk: add include for macro definition

[Jerin Jacob]

On Wed, Jun 15, 2022 at 10:41 PM Bruce Richardson
<bruce.richardson@intel.com> wrote:
>
> The header file "roc_io.h" uses the "__plt_always_inline" macro but
> don't include "roc_platform.h" to get the definition of it. This
> inclusion is not necessary for compilation, but the lack of it can
> confuse some indexers - such as those in eclipse, which reports the
> lines:
>
> "static __plt_always_inline uint64_t"
>
> as possible definitions of a variable called "uint64_t". This confusion
> leads to uint64_t being flagged as an unknown type in all other parts of
> the project being indexed, e.g. across all of DPDK code.
>
> Adding in the include of roc_platform.h makes it clear to the indexer
> that those lines are  part of a function definition, and that allows
> eclipse to correctly recognise uint64_t as a type from stdint.h
>
> Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>

Acked-by: Jerin Jacob <jerinj@marvell.com>
Applied  2/2 patch to dpdk-next-net-mrvl/for-next-net. Thanks

1/2 patch is delegated to Thomas.

> ---
> V2: fix copy-paste error, where header name replacement was missed
> ---
>  drivers/common/cnxk/roc_io.h | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/drivers/common/cnxk/roc_io.h b/drivers/common/cnxk/roc_io.h
> index 62e98d9d00..9d73e263f7 100644
> --- a/drivers/common/cnxk/roc_io.h
> +++ b/drivers/common/cnxk/roc_io.h
> @@ -5,6 +5,8 @@
>  #ifndef _ROC_IO_H_
>  #define _ROC_IO_H_
>
> +#include "roc_platform.h" /* for __plt_always_inline macro */
> +
>  #define ROC_LMT_BASE_ID_GET(lmt_addr, lmt_id)                                  \
>         do {                                                                   \
>                 /* 32 Lines per core */                                        \
> --
> 2.34.1
>