Re: [PATCH v6 12/30] drivers/event: replace packed attributes
On Tue, Nov 26, 2024 at 04:52:23PM -0800, Andre Muezerie wrote: > MSVC struct packing is not compatible with GCC. Replace macro > __rte_packed with __rte_packed_begin to push existing pack value > and set packing to 1-byte and macro __rte_packed_end to restore > the pack value prior to the push. > > Macro __rte_packed_end is deliberately utilized to trigger a > MSVC compiler warning if no existing packing has been pushed allowing > easy identification of locations where the __rte_packed_begin is > missing. > > Signed-off-by: Andre Muezerie > --- Reviewed-by: Tyler Retzlaff
Re: [PATCH v6 15/30] drivers/raw: replace packed attributes
On Tue, Nov 26, 2024 at 04:52:26PM -0800, Andre Muezerie wrote: > MSVC struct packing is not compatible with GCC. Replace macro > __rte_packed with __rte_packed_begin to push existing pack value > and set packing to 1-byte and macro __rte_packed_end to restore > the pack value prior to the push. > > Macro __rte_packed_end is deliberately utilized to trigger a > MSVC compiler warning if no existing packing has been pushed allowing > easy identification of locations where the __rte_packed_begin is > missing. > > Signed-off-by: Andre Muezerie > --- Reviewed-by: Tyler Retzlaff
[PATCH v3 1/7] lib/eal: eliminate dependency on non-portable __SIZEOF_LONG__
Macro __SIZEOF_LONG__ is not standardized and MSVC does not define it.
Therefore the errors below are seen with MSVC:
../lib/mldev/mldev_utils_scalar.c(465): error C2065:
'__SIZEOF_LONG__': undeclared identifier
../lib/mldev/mldev_utils_scalar.c(478): error C2051:
case expression not constant
../lib/mldev/mldev_utils_scalar_bfloat16.c(33): error C2065:
'__SIZEOF_LONG__': undeclared identifier
../lib/mldev/mldev_utils_scalar_bfloat16.c(49): error C2051:
case expression not constant
Turns out that the places where __SIZEOF_LONG__ is currently
being used can equally well use sizeof(long) instead.
Signed-off-by: Andre Muezerie
---
lib/eal/include/rte_common.h | 5 +
1 file changed, 5 insertions(+)
diff --git a/lib/eal/include/rte_common.h b/lib/eal/include/rte_common.h
index 4d299f2b36..d2338366a4 100644
--- a/lib/eal/include/rte_common.h
+++ b/lib/eal/include/rte_common.h
@@ -603,6 +603,11 @@ rte_is_aligned(const void * const __rte_restrict ptr,
const unsigned int align)
*/
#define RTE_BUILD_BUG_ON(condition) do { static_assert(!(condition),
#condition); } while (0)
+/*** Data type size related macros /
+
+#define RTE_BITS_PER_LONG (sizeof(long) * 8)
+#define RTE_BITS_PER_LONG_LONG (sizeof(long long) * 8)
+
/*** Cache line related macros /
/** Cache line mask. */
--
2.47.0.vfs.0.3
Re: [PATCH 0/6] eliminate dependency on non-portable __SIZEOF_LONG__
On Wed, Dec 04, 2024 at 01:50:58PM -0800, Stephen Hemminger wrote: > On Wed, 4 Dec 2024 12:09:49 -0800 > Andre Muezerie wrote: > > > Macro __SIZEOF_LONG__ is not standardized and MSVC does not define it. > > Therefore the errors below are seen with MSVC: > > > > ../lib/mldev/mldev_utils_scalar.c(465): error C2065: > > '__SIZEOF_LONG__': undeclared identifier > > ../lib/mldev/mldev_utils_scalar.c(478): error C2051: > > case expression not constant > > > > ../lib/mldev/mldev_utils_scalar_bfloat16.c(33): error C2065: > > '__SIZEOF_LONG__': undeclared identifier > > ../lib/mldev/mldev_utils_scalar_bfloat16.c(49): error C2051: > > case expression not constant > > > > Turns out that the places where __SIZEOF_LONG__ is currently > > being used can equaly well use sizeof(long) instead. > > > > Andre Muezerie (6): > > drivers/bus: eliminate dependency on non-portable __SIZEOF_LONG__ > > drivers/common: eliminate dependency on non-portable __SIZEOF_LONG__ > > drivers/dma: eliminate dependency on non-portable __SIZEOF_LONG__ > > drivers/net: eliminate dependency on non-portable __SIZEOF_LONG__ > > drivers/raw: eliminate dependency on non-portable __SIZEOF_LONG__ > > lib/mldev: eliminate dependency on non-portable __SIZEOF_LONG__ > > > > drivers/bus/fslmc/mc/fsl_mc_cmd.h| 2 +- > > drivers/common/cnxk/roc_bits.h | 4 ++-- > > drivers/common/nfp/nfp_platform.h| 4 ++-- > > drivers/dma/dpaa/dpaa_qdma.h | 2 +- > > drivers/dma/hisilicon/hisi_dmadev.h | 2 +- > > drivers/net/ena/base/ena_plat_dpdk.h | 4 ++-- > > drivers/net/hns3/hns3_ethdev.h | 2 +- > > drivers/raw/ifpga/base/opae_osdep.h | 4 ++-- > > lib/mldev/mldev_utils_scalar.h | 2 +- > > 9 files changed, 13 insertions(+), 13 deletions(-) > > > > -- > > BITS_PER_LONG etc should be in rte_common.h not scattered > all over these drivers. Makes sense. I'll update the series, but will limit the additional changes to BITS_PER_LONG and BITS_PER_LONG_LONG to limit the size of this series. -- Andre Muezerie
[PATCH v3 5/7] drivers/net: eliminate dependency on non-portable __SIZEOF_LONG__
Macro __SIZEOF_LONG__ is not standardized and MSVC does not define it. Therefore the errors below are seen with MSVC: ../lib/mldev/mldev_utils_scalar.c(465): error C2065: '__SIZEOF_LONG__': undeclared identifier ../lib/mldev/mldev_utils_scalar.c(478): error C2051: case expression not constant ../lib/mldev/mldev_utils_scalar_bfloat16.c(33): error C2065: '__SIZEOF_LONG__': undeclared identifier ../lib/mldev/mldev_utils_scalar_bfloat16.c(49): error C2051: case expression not constant Turns out that the places where __SIZEOF_LONG__ is currently being used can equally well use sizeof(long) instead. Signed-off-by: Andre Muezerie --- drivers/net/ena/base/ena_plat_dpdk.h | 6 ++ drivers/net/hns3/hns3_ethdev.h | 3 +-- 2 files changed, 3 insertions(+), 6 deletions(-) diff --git a/drivers/net/ena/base/ena_plat_dpdk.h b/drivers/net/ena/base/ena_plat_dpdk.h index 1121460470..63f6ef70ee 100644 --- a/drivers/net/ena/base/ena_plat_dpdk.h +++ b/drivers/net/ena/base/ena_plat_dpdk.h @@ -97,14 +97,12 @@ extern int ena_logtype_com; #define ENA_MIN16(x, y) ENA_MIN_T(uint16_t, (x), (y)) #define ENA_MIN8(x, y) ENA_MIN_T(uint8_t, (x), (y)) -#define BITS_PER_LONG_LONG (__SIZEOF_LONG_LONG__ * 8) #define U64_C(x) x ## ULL #define BIT(nr)RTE_BIT32(nr) #define BIT64(nr) RTE_BIT64(nr) -#define BITS_PER_LONG (__SIZEOF_LONG__ * 8) -#define GENMASK(h, l) (((~0UL) << (l)) & (~0UL >> (BITS_PER_LONG - 1 - (h +#define GENMASK(h, l) (((~0UL) << (l)) & (~0UL >> (RTE_BITS_PER_LONG - 1 - (h #define GENMASK_ULL(h, l) (((~0ULL) - (1ULL << (l)) + 1) &\ - (~0ULL >> (BITS_PER_LONG_LONG - 1 - (h + (~0ULL >> (RTE_BITS_PER_LONG_LONG - 1 - (h #define ena_trc_log(dev, level, fmt, arg...) \ ( \ diff --git a/drivers/net/hns3/hns3_ethdev.h b/drivers/net/hns3/hns3_ethdev.h index 7824503bb8..c7ad9a61c7 100644 --- a/drivers/net/hns3/hns3_ethdev.h +++ b/drivers/net/hns3/hns3_ethdev.h @@ -952,9 +952,8 @@ static inline struct hns3_vf *HNS3_DEV_HW_TO_VF(struct hns3_hw *hw) #define BIT_ULL(x) (1ULL << (x)) -#define BITS_PER_LONG (__SIZEOF_LONG__ * 8) #define GENMASK(h, l) \ - (((~0UL) << (l)) & (~0UL >> (BITS_PER_LONG - 1 - (h + (((~0UL) << (l)) & (~0UL >> (RTE_BITS_PER_LONG - 1 - (h #define roundup(x, y) x) + ((y) - 1)) / (y)) * (y)) #define rounddown(x, y) ((x) - ((x) % (y))) -- 2.47.0.vfs.0.3
[PATCH v3 2/7] drivers/bus: eliminate dependency on non-portable __SIZEOF_LONG__
Macro __SIZEOF_LONG__ is not standardized and MSVC does not define it.
Therefore the errors below are seen with MSVC:
../lib/mldev/mldev_utils_scalar.c(465): error C2065:
'__SIZEOF_LONG__': undeclared identifier
../lib/mldev/mldev_utils_scalar.c(478): error C2051:
case expression not constant
../lib/mldev/mldev_utils_scalar_bfloat16.c(33): error C2065:
'__SIZEOF_LONG__': undeclared identifier
../lib/mldev/mldev_utils_scalar_bfloat16.c(49): error C2051:
case expression not constant
Turns out that the places where __SIZEOF_LONG__ is currently
being used can equally well use sizeof(long) instead.
Signed-off-by: Andre Muezerie
---
drivers/bus/fslmc/mc/fsl_mc_cmd.h | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/bus/fslmc/mc/fsl_mc_cmd.h
b/drivers/bus/fslmc/mc/fsl_mc_cmd.h
index a768774c89..f27a18905d 100644
--- a/drivers/bus/fslmc/mc/fsl_mc_cmd.h
+++ b/drivers/bus/fslmc/mc/fsl_mc_cmd.h
@@ -29,9 +29,8 @@
#define le32_to_cpurte_le_to_cpu_32
#define le16_to_cpurte_le_to_cpu_16
-#define BITS_PER_LONG (__SIZEOF_LONG__ * 8)
#define GENMASK(h, l) \
- (((~0UL) << (l)) & (~0UL >> (BITS_PER_LONG - 1 - (h
+ (((~0UL) << (l)) & (~0UL >> (RTE_BITS_PER_LONG - 1 - (h
struct mc_cmd_header {
union {
--
2.47.0.vfs.0.3
[PATCH v3 0/7] eliminate dependency on non-portable __SIZEOF_LONG__
Macro __SIZEOF_LONG__ is not standardized and MSVC does not define it. Therefore the errors below are seen with MSVC: ../lib/mldev/mldev_utils_scalar.c(465): error C2065: '__SIZEOF_LONG__': undeclared identifier ../lib/mldev/mldev_utils_scalar.c(478): error C2051: case expression not constant ../lib/mldev/mldev_utils_scalar_bfloat16.c(33): error C2065: '__SIZEOF_LONG__': undeclared identifier ../lib/mldev/mldev_utils_scalar_bfloat16.c(49): error C2051: case expression not constant Turns out that the places where __SIZEOF_LONG__ is currently being used can equally well use sizeof(long) instead. v3: * added prefix RTE_ to BITS_PER_LONG* and moved them to rte_common.h * defined PLT_BITS_PER_LONG* in drivers/common/cnxk/roc_platform.h to avoid warnings from checkpatches.sh like: Warning in drivers/common/cnxk/roc_bits.h: Warning in drivers/common/cnxk/roc_ie_ot.h: Warning in drivers/common/cnxk/roc_ie_ot_tls.h: Use plt_ symbols instead of rte_ API in cnxk base driver It can be seen that the same was done in the past for similar macros like PLT_CACHE_LINE_SIZE v2: * fixed typo in commit message Andre Muezerie (7): lib/eal: eliminate dependency on non-portable __SIZEOF_LONG__ drivers/bus: eliminate dependency on non-portable __SIZEOF_LONG__ drivers/common: eliminate dependency on non-portable __SIZEOF_LONG__ drivers/dma: eliminate dependency on non-portable __SIZEOF_LONG__ drivers/net: eliminate dependency on non-portable __SIZEOF_LONG__ drivers/raw: eliminate dependency on non-portable __SIZEOF_LONG__ lib/mldev: eliminate dependency on non-portable __SIZEOF_LONG__ drivers/bus/fslmc/mc/fsl_mc_cmd.h | 3 +-- drivers/common/cnxk/cnxk_security_ar.h | 4 ++-- drivers/common/cnxk/roc_bits.h | 13 - drivers/common/cnxk/roc_ie_ot.h| 4 ++-- drivers/common/cnxk/roc_ie_ot_tls.h| 5 +++-- drivers/common/cnxk/roc_platform.h | 2 ++ drivers/common/nfp/nfp_platform.h | 8 +++- drivers/dma/dpaa/dpaa_qdma.h | 3 +-- drivers/dma/hisilicon/hisi_dmadev.h| 3 +-- drivers/net/ena/base/ena_plat_dpdk.h | 6 ++ drivers/net/hns3/hns3_ethdev.h | 3 +-- drivers/raw/ifpga/base/opae_osdep.h| 12 lib/eal/include/rte_common.h | 5 + lib/mldev/mldev_utils_scalar.h | 6 +- 14 files changed, 32 insertions(+), 45 deletions(-) -- 2.47.0.vfs.0.3
[PATCH v3 6/7] drivers/raw: eliminate dependency on non-portable __SIZEOF_LONG__
Macro __SIZEOF_LONG__ is not standardized and MSVC does not define it.
Therefore the errors below are seen with MSVC:
../lib/mldev/mldev_utils_scalar.c(465): error C2065:
'__SIZEOF_LONG__': undeclared identifier
../lib/mldev/mldev_utils_scalar.c(478): error C2051:
case expression not constant
../lib/mldev/mldev_utils_scalar_bfloat16.c(33): error C2065:
'__SIZEOF_LONG__': undeclared identifier
../lib/mldev/mldev_utils_scalar_bfloat16.c(49): error C2051:
case expression not constant
Turns out that the places where __SIZEOF_LONG__ is currently
being used can equally well use sizeof(long) instead.
Signed-off-by: Andre Muezerie
---
drivers/raw/ifpga/base/opae_osdep.h | 12
1 file changed, 4 insertions(+), 8 deletions(-)
diff --git a/drivers/raw/ifpga/base/opae_osdep.h
b/drivers/raw/ifpga/base/opae_osdep.h
index cb780b1fed..e4767e2d7a 100644
--- a/drivers/raw/ifpga/base/opae_osdep.h
+++ b/drivers/raw/ifpga/base/opae_osdep.h
@@ -9,6 +9,8 @@
#include
#include
+#include
+
#ifdef RTE_LIB_EAL
#include "osdep_rte/osdep_generic.h"
#else
@@ -30,12 +32,6 @@ struct uuid {
};
#ifndef LINUX_MACROS
-#ifndef BITS_PER_LONG
-#define BITS_PER_LONG (__SIZEOF_LONG__ * 8)
-#endif
-#ifndef BITS_PER_LONG_LONG
-#define BITS_PER_LONG_LONG (__SIZEOF_LONG_LONG__ * 8)
-#endif
#ifndef BIT
#define BIT(a) (1UL << (a))
#endif /* BIT */
@@ -43,11 +39,11 @@ struct uuid {
#define BIT_ULL(a) (1ULL << (a))
#endif /* BIT_ULL */
#ifndef GENMASK
-#define GENMASK(h, l) (((~0UL) << (l)) & (~0UL >> (BITS_PER_LONG - 1 - (h
+#define GENMASK(h, l) (((~0UL) << (l)) & (~0UL >> (RTE_BITS_PER_LONG - 1 -
(h
#endif /* GENMASK */
#ifndef GENMASK_ULL
#define GENMASK_ULL(h, l) \
- (((~0ULL) << (l)) & (~0ULL >> (BITS_PER_LONG_LONG - 1 - (h
+ (((~0ULL) << (l)) & (~0ULL >> (RTE_BITS_PER_LONG_LONG - 1 - (h
#endif /* GENMASK_ULL */
#endif /* LINUX_MACROS */
--
2.47.0.vfs.0.3
[PATCH v3 7/7] lib/mldev: eliminate dependency on non-portable __SIZEOF_LONG__
Macro __SIZEOF_LONG__ is not standardized and MSVC does not define it. Therefore the errors below are seen with MSVC: ../lib/mldev/mldev_utils_scalar.c(465): error C2065: '__SIZEOF_LONG__': undeclared identifier ../lib/mldev/mldev_utils_scalar.c(478): error C2051: case expression not constant ../lib/mldev/mldev_utils_scalar_bfloat16.c(33): error C2065: '__SIZEOF_LONG__': undeclared identifier ../lib/mldev/mldev_utils_scalar_bfloat16.c(49): error C2051: case expression not constant Turns out that the places where __SIZEOF_LONG__ is currently being used can equally well use sizeof(long) instead. Signed-off-by: Andre Muezerie --- lib/mldev/mldev_utils_scalar.h | 6 +- 1 file changed, 1 insertion(+), 5 deletions(-) diff --git a/lib/mldev/mldev_utils_scalar.h b/lib/mldev/mldev_utils_scalar.h index 57e66ddb60..a9462089d7 100644 --- a/lib/mldev/mldev_utils_scalar.h +++ b/lib/mldev/mldev_utils_scalar.h @@ -12,12 +12,8 @@ #define BIT(nr) (1UL << (nr)) #endif -#ifndef BITS_PER_LONG -#define BITS_PER_LONG (__SIZEOF_LONG__ * 8) -#endif - #ifndef GENMASK_U32 -#define GENMASK_U32(h, l) (((~0UL) << (l)) & (~0UL >> (BITS_PER_LONG - 1 - (h +#define GENMASK_U32(h, l) (((~0UL) << (l)) & (~0UL >> (RTE_BITS_PER_LONG - 1 - (h #endif /* float32: bit index of MSB & LSB of sign, exponent and mantissa */ -- 2.47.0.vfs.0.3
Re: [PATCH v5 01/16] eal: provide pack start macro for MSVC
On Tue, Nov 19, 2024 at 09:32:07AM +0100, Morten Brørup wrote: > > From: Andre Muezerie [mailto:andre...@linux.microsoft.com] > > Sent: Tuesday, 19 November 2024 05.35 > > > > From: Tyler Retzlaff > > > > MSVC struct packing is not compatible with GCC. Provide a macro that > > can be used to push existing pack value and sets packing to 1-byte. > > The existing __rte_packed macro is then used to restore the pack value > > prior to the push. > > > > Instead of providing macros exclusively for MSVC and for GCC the > > existing macro is deliberately utilized to trigger a warning if no > > existing packing has been pushed allowing easy identification of > > locations where the __rte_msvc_pack is missing. > > > > Signed-off-by: Tyler Retzlaff > > --- > > lib/eal/include/rte_common.h | 4 +++- > > 1 file changed, 3 insertions(+), 1 deletion(-) > > > > diff --git a/lib/eal/include/rte_common.h > > b/lib/eal/include/rte_common.h > > index 4d299f2b36..409890863e 100644 > > --- a/lib/eal/include/rte_common.h > > +++ b/lib/eal/include/rte_common.h > > @@ -103,8 +103,10 @@ typedef uint16_t unaligned_uint16_t; > > * Force a structure to be packed > > */ > > #ifdef RTE_TOOLCHAIN_MSVC > > -#define __rte_packed > > +#define __rte_msvc_pack __pragma(pack(push, 1)) > > +#define __rte_packed __pragma(pack(pop)) > > #else > > +#define __rte_msvc_pack > > #define __rte_packed __attribute__((__packed__)) > > #endif > > > > -- > > 2.47.0.vfs.0.3 > > Before proceeding with this, can we please discuss the alternative, proposed > here: > https://inbox.dpdk.org/dev/cajfav8ystgibbe+nkt9mc30r0+zp64_kgurhozqd90rd2hx...@mail.gmail.com/ > > The definition of the packing macro in OVS, for reference: > https://github.com/openvswitch/ovs/blob/main/include/openvswitch/compiler.h#L209 > > The current solution requires __rte_packed to be placed at the end of a > structure, although __attribute__((packed)) is normally allowed at the > beginning (between the "struct" tag and the name of the structure), which > introduces a high risk of contributors placing it "incorrectly", thus causing > errors. > > I have a strong preference for an __RTE_PACKED(decl) variant. > > Here's a third alternative: > #ifdef RTE_TOOLCHAIN_MSVC > #define __rte_msvc_pack_begin __pragma(pack(push, 1)) > #define __rte_msvc_pack_end __pragma(pack(pop)) > #else > #define __rte_msvc_pack_begin > #define __rte_msvc_pack_end > #endif > > The third alternative is also problematic, e.g. if a contributor forgets the > _end after the structure declaration, or adds another structure declaration > before the _end. so just some additional info here. for the compiler that cares about the end (i.e. msvc) msvc actually emits a warning (treated as error) if a push pack is not closed with a pop pack within a header or a tu. that's one of the benefits of the macros in original proposal. > > -Morten
Re: [PATCH v6 05/30] doc/guides: replace packed attributes
On Tue, Nov 26, 2024 at 04:52:16PM -0800, Andre Muezerie wrote: > MSVC struct packing is not compatible with GCC. Replace macro > __rte_packed with __rte_packed_begin to push existing pack value > and set packing to 1-byte and macro __rte_packed_end to restore > the pack value prior to the push. > > Macro __rte_packed_end is deliberately utilized to trigger a > MSVC compiler warning if no existing packing has been pushed allowing > easy identification of locations where the __rte_packed_begin is > missing. > > Signed-off-by: Andre Muezerie > --- Acked-by: Tyler Retzlaff
Re: [PATCH v6 30/30] lib/eal: remove __rte_packed
On Tue, Nov 26, 2024 at 04:52:41PM -0800, Andre Muezerie wrote: > Remove macro __rte_packed now that the code was made portable using > __rte_packed_begin to push existing pack value > and set packing to 1-byte and macro __rte_packed_end to restore > the pack value prior to the push when MSVC is used. > > Signed-off-by: Andre Muezerie > --- Acked-by: Tyler Retzlaff
Re: [PATCH v6 01/30] devtools: check packed attributes
On Tue, Nov 26, 2024 at 04:52:12PM -0800, Andre Muezerie wrote: > Ensure __rte_packed_begin and __rte_packed_end show up in pairs > when checking patches. > > Signed-off-by: Andre Muezerie > --- Acked-by: Tyler Retzlaff
RE: [PATCH 2/6] drivers/common: eliminate dependency on non-portable __SIZEOF_LONG__
> Macro __SIZEOF_LONG__ is not standardized and MSVC does not define it. > Therefore the errors below are seen with MSVC: > > ../lib/mldev/mldev_utils_scalar.c(465): error C2065: > '__SIZEOF_LONG__': undeclared identifier > ../lib/mldev/mldev_utils_scalar.c(478): error C2051: > case expression not constant > > ../lib/mldev/mldev_utils_scalar_bfloat16.c(33): error C2065: > '__SIZEOF_LONG__': undeclared identifier > ../lib/mldev/mldev_utils_scalar_bfloat16.c(49): error C2051: > case expression not constant > > Turns out that the places where __SIZEOF_LONG__ is currently being used can > equaly well use sizeof(long) instead. > > Signed-off-by: Andre Muezerie > --- > drivers/common/cnxk/roc_bits.h| 4 ++-- > drivers/common/nfp/nfp_platform.h | 4 ++-- > 2 files changed, 4 insertions(+), 4 deletions(-) > > diff --git a/drivers/common/cnxk/roc_bits.h > b/drivers/common/cnxk/roc_bits.h index 11216d9d63..aa4944ae7f 100644 > --- a/drivers/common/cnxk/roc_bits.h > +++ b/drivers/common/cnxk/roc_bits.h > @@ -14,10 +14,10 @@ > #endif > > #ifndef BITS_PER_LONG > -#define BITS_PER_LONG (__SIZEOF_LONG__ * 8) > +#define BITS_PER_LONG (sizeof(long) * 8) > #endif > #ifndef BITS_PER_LONG_LONG > -#define BITS_PER_LONG_LONG (__SIZEOF_LONG_LONG__ * 8) > +#define BITS_PER_LONG_LONG (sizeof(long long) * 8) > #endif > > #ifndef GENMASK > diff --git a/drivers/common/nfp/nfp_platform.h > b/drivers/common/nfp/nfp_platform.h > index 0b02fcf1e8..27792aca97 100644 > --- a/drivers/common/nfp/nfp_platform.h > +++ b/drivers/common/nfp/nfp_platform.h > @@ -14,8 +14,8 @@ > > #define DMA_BIT_MASK(n)((1ULL << (n)) - 1) > > -#define BITS_PER_LONG (__SIZEOF_LONG__ * 8) > -#define BITS_PER_LONG_LONG (__SIZEOF_LONG_LONG__ * 8) > +#define BITS_PER_LONG (sizeof(long) * 8) > +#define BITS_PER_LONG_LONG (sizeof(long long) * 8) This looks good to me, thanks. Acked-by: Chaoyong He > > #define GENMASK(h, l) \ > ((~0UL << (l)) & (~0UL >> (BITS_PER_LONG - (h) - 1))) > -- > 2.47.0.vfs.0.3
Re: [PATCH v6 02/30] eal/include: add new packing macros
On Tue, Nov 26, 2024 at 04:52:13PM -0800, Andre Muezerie wrote: > MSVC struct packing is not compatible with GCC. Add macro > __rte_packed_begin which can be used to push existing pack value > and set packing to 1-byte. Add macro __rte_packed_end to restore > the pack value prior to the push. > > Macro __rte_packed_end is deliberately utilized to trigger a > MSVC compiler warning if no existing packing has been pushed allowing > easy identification of locations where the __rte_packed_begin is > missing. > > Macro __rte_packed will be removed in a subsequent patch. > > Signed-off-by: Andre Muezerie > --- Acked-by: Tyler Retzlaff
Re: [PATCH v6 07/30] drivers/bus: replace packed attributes
On Tue, Nov 26, 2024 at 04:52:18PM -0800, Andre Muezerie wrote: > MSVC struct packing is not compatible with GCC. Replace macro > __rte_packed with __rte_packed_begin to push existing pack value > and set packing to 1-byte and macro __rte_packed_end to restore > the pack value prior to the push. > > Macro __rte_packed_end is deliberately utilized to trigger a > MSVC compiler warning if no existing packing has been pushed allowing > easy identification of locations where the __rte_packed_begin is > missing. > > Signed-off-by: Andre Muezerie > --- Reviewed-by: Tyler Retzlaff
Re: [PATCH v6 09/30] drivers/compress: replace packed attributes
On Tue, Nov 26, 2024 at 04:52:20PM -0800, Andre Muezerie wrote: > MSVC struct packing is not compatible with GCC. Replace macro > __rte_packed with __rte_packed_begin to push existing pack value > and set packing to 1-byte and macro __rte_packed_end to restore > the pack value prior to the push. > > Macro __rte_packed_end is deliberately utilized to trigger a > MSVC compiler warning if no existing packing has been pushed allowing > easy identification of locations where the __rte_packed_begin is > missing. > > Signed-off-by: Andre Muezerie > --- Reviewed-by: Tyler Retzlaff
Re: [PATCH v6 10/30] drivers/crypto: replace packed attributes
On Tue, Nov 26, 2024 at 04:52:21PM -0800, Andre Muezerie wrote: > MSVC struct packing is not compatible with GCC. Replace macro > __rte_packed with __rte_packed_begin to push existing pack value > and set packing to 1-byte and macro __rte_packed_end to restore > the pack value prior to the push. > > Macro __rte_packed_end is deliberately utilized to trigger a > MSVC compiler warning if no existing packing has been pushed allowing > easy identification of locations where the __rte_packed_begin is > missing. > > Signed-off-by: Andre Muezerie > --- Reviewed-by: Tyler Retzlaff
Re: [PATCH v6 13/30] drivers/mempool: replace packed attributes
On Tue, Nov 26, 2024 at 04:52:24PM -0800, Andre Muezerie wrote: > MSVC struct packing is not compatible with GCC. Replace macro > __rte_packed with __rte_packed_begin to push existing pack value > and set packing to 1-byte and macro __rte_packed_end to restore > the pack value prior to the push. > > Macro __rte_packed_end is deliberately utilized to trigger a > MSVC compiler warning if no existing packing has been pushed allowing > easy identification of locations where the __rte_packed_begin is > missing. > > Signed-off-by: Andre Muezerie > --- Reviewed-by: Tyler Retzlaff
Re: [PATCH 4/6] eal: add unit tests for atomic bitset operations
On Wed, Oct 09, 2024 at 10:29:01PM +0200, Morten Brørup wrote: > > From: Tyler Retzlaff [mailto:roret...@linux.microsoft.com] > > Sent: Thursday, 12 September 2024 06.52 > > > > On Fri, Aug 09, 2024 at 10:14:38PM +0200, Mattias R??nnblom wrote: > > > Extend bitset tests to cover the basic operation of the > > > rte_bitset_atomic_*() family of functions. > > > > > > Signed-off-by: Mattias R??nnblom > > > --- > > > > Tyler Retzlaff > > Fixing this, for the benefit of Patchwork... > > Acked-by: Tyler Retzlaff thank you
Re: [PATCH v6 06/30] drivers/baseband: replace packed attributes
On Tue, Nov 26, 2024 at 04:52:17PM -0800, Andre Muezerie wrote: > MSVC struct packing is not compatible with GCC. Replace macro > __rte_packed with __rte_packed_begin to push existing pack value > and set packing to 1-byte and macro __rte_packed_end to restore > the pack value prior to the push. > > Macro __rte_packed_end is deliberately utilized to trigger a > MSVC compiler warning if no existing packing has been pushed allowing > easy identification of locations where the __rte_packed_begin is > missing. > > Signed-off-by: Andre Muezerie > --- Reviewed-by: Tyler Retlzaff
Re: [PATCH v6 11/30] drivers/dma: replace packed attributes
On Tue, Nov 26, 2024 at 04:52:22PM -0800, Andre Muezerie wrote: > MSVC struct packing is not compatible with GCC. Replace macro > __rte_packed with __rte_packed_begin to push existing pack value > and set packing to 1-byte and macro __rte_packed_end to restore > the pack value prior to the push. > > Macro __rte_packed_end is deliberately utilized to trigger a > MSVC compiler warning if no existing packing has been pushed allowing > easy identification of locations where the __rte_packed_begin is > missing. > > Signed-off-by: Andre Muezerie > --- Reviewed-by: Tyler Retzlaff
RE: [PATCH v2 2/2] net/bonding: add command to set dedicated queue size
> On Wed, 4 Dec 2024 06:21:00 + > Chaoyong He wrote: > > > > The definition of what a "dedicated queue" is a bit confusing. > > > If it is only for LACP packets, it should never need to be very big. > > > Only under a mis-configuration and DoS kind of flood should there > > > ever be many packets. > > > > Yes, the dedicated queue is only for LACP packets now and it doesn't need be > set very big. > > > > But if we use a hardware queue as the "dedicated queue", we must > > consider the hardware capability. The minimum queue size of some NICs > > may be larger than the hardcode dedicated queue size. In this case, I think > > it > is better to add an interface to set the dedicated queue size. > > How about using the existing descriptor queue limits api for that? > It is reported by info get Using existing descriptor queue limits api is good enough for current problem(hardware capability), but I think it is not very flexible. Now we use a macro as a default value for dedicated queue size, but we can replace the macro with queue limit while still retaining the interface for modifying queue size. What do you think of this?
[PATCH v3 4/7] drivers/dma: eliminate dependency on non-portable __SIZEOF_LONG__
Macro __SIZEOF_LONG__ is not standardized and MSVC does not define it. Therefore the errors below are seen with MSVC: ../lib/mldev/mldev_utils_scalar.c(465): error C2065: '__SIZEOF_LONG__': undeclared identifier ../lib/mldev/mldev_utils_scalar.c(478): error C2051: case expression not constant ../lib/mldev/mldev_utils_scalar_bfloat16.c(33): error C2065: '__SIZEOF_LONG__': undeclared identifier ../lib/mldev/mldev_utils_scalar_bfloat16.c(49): error C2051: case expression not constant Turns out that the places where __SIZEOF_LONG__ is currently being used can equally well use sizeof(long) instead. Signed-off-by: Andre Muezerie --- drivers/dma/dpaa/dpaa_qdma.h| 3 +-- drivers/dma/hisilicon/hisi_dmadev.h | 3 +-- 2 files changed, 2 insertions(+), 4 deletions(-) diff --git a/drivers/dma/dpaa/dpaa_qdma.h b/drivers/dma/dpaa/dpaa_qdma.h index 91eaf1455a..617e15fbc4 100644 --- a/drivers/dma/dpaa/dpaa_qdma.h +++ b/drivers/dma/dpaa/dpaa_qdma.h @@ -14,9 +14,8 @@ #define RETRIES5 #ifndef GENMASK -#define BITS_PER_LONG (__SIZEOF_LONG__ * 8) #define GENMASK(h, l) \ - (((~0UL) << (l)) & (~0UL >> (BITS_PER_LONG - 1 - (h + (((~0UL) << (l)) & (~0UL >> (RTE_BITS_PER_LONG - 1 - (h #endif #define QDMA_CTRL_REGION_OFFSET 0 diff --git a/drivers/dma/hisilicon/hisi_dmadev.h b/drivers/dma/hisilicon/hisi_dmadev.h index 786fe3cc0e..d1b4ae7da8 100644 --- a/drivers/dma/hisilicon/hisi_dmadev.h +++ b/drivers/dma/hisilicon/hisi_dmadev.h @@ -12,9 +12,8 @@ #include #define BIT(x) (1ul << (x)) -#define BITS_PER_LONG (__SIZEOF_LONG__ * 8) #define GENMASK(h, l) \ - (((~0UL) << (l)) & (~0UL >> (BITS_PER_LONG - 1 - (h + (((~0UL) << (l)) & (~0UL >> (RTE_BITS_PER_LONG - 1 - (h #define BF_SHF(x) rte_bsf64(x) #define FIELD_GET(mask, reg) \ ((typeof(mask))(((reg) & (mask)) >> BF_SHF(mask))) -- 2.47.0.vfs.0.3
[PATCH v3 3/7] drivers/common: eliminate dependency on non-portable __SIZEOF_LONG__
Macro __SIZEOF_LONG__ is not standardized and MSVC does not define it. Therefore the errors below are seen with MSVC: ../lib/mldev/mldev_utils_scalar.c(465): error C2065: '__SIZEOF_LONG__': undeclared identifier ../lib/mldev/mldev_utils_scalar.c(478): error C2051: case expression not constant ../lib/mldev/mldev_utils_scalar_bfloat16.c(33): error C2065: '__SIZEOF_LONG__': undeclared identifier ../lib/mldev/mldev_utils_scalar_bfloat16.c(49): error C2051: case expression not constant Turns out that the places where __SIZEOF_LONG__ is currently being used can equally well use sizeof(long) instead. Signed-off-by: Andre Muezerie Acked-by: Chaoyong He --- drivers/common/cnxk/cnxk_security_ar.h | 4 ++-- drivers/common/cnxk/roc_bits.h | 13 - drivers/common/cnxk/roc_ie_ot.h| 4 ++-- drivers/common/cnxk/roc_ie_ot_tls.h| 5 +++-- drivers/common/cnxk/roc_platform.h | 2 ++ drivers/common/nfp/nfp_platform.h | 8 +++- 6 files changed, 16 insertions(+), 20 deletions(-) diff --git a/drivers/common/cnxk/cnxk_security_ar.h b/drivers/common/cnxk/cnxk_security_ar.h index d0151a752c..9e88d0063b 100644 --- a/drivers/common/cnxk/cnxk_security_ar.h +++ b/drivers/common/cnxk/cnxk_security_ar.h @@ -13,8 +13,8 @@ /* u64 array size to fit anti replay window bits */ #define AR_WIN_ARR_SZ \ - (PLT_ALIGN_CEIL(CNXK_ON_AR_WIN_SIZE_MAX + 1, BITS_PER_LONG_LONG) / \ -BITS_PER_LONG_LONG) + (PLT_ALIGN_CEIL(CNXK_ON_AR_WIN_SIZE_MAX + 1, PLT_BITS_PER_LONG_LONG) / \ +PLT_BITS_PER_LONG_LONG) #define WORD_SHIFT 6 #define WORD_SIZE (1ULL << WORD_SHIFT) diff --git a/drivers/common/cnxk/roc_bits.h b/drivers/common/cnxk/roc_bits.h index 11216d9d63..654e5a85d7 100644 --- a/drivers/common/cnxk/roc_bits.h +++ b/drivers/common/cnxk/roc_bits.h @@ -5,6 +5,8 @@ #ifndef _ROC_BITS_H_ #define _ROC_BITS_H_ +#include + #ifndef BIT_ULL #define BIT_ULL(nr) (1ULL << (nr)) #endif @@ -13,20 +15,13 @@ #define BIT(nr) (1UL << (nr)) #endif -#ifndef BITS_PER_LONG -#define BITS_PER_LONG (__SIZEOF_LONG__ * 8) -#endif -#ifndef BITS_PER_LONG_LONG -#define BITS_PER_LONG_LONG (__SIZEOF_LONG_LONG__ * 8) -#endif - #ifndef GENMASK -#define GENMASK(h, l) (((~0UL) << (l)) & (~0UL >> (BITS_PER_LONG - 1 - (h +#define GENMASK(h, l) (((~0UL) << (l)) & (~0UL >> (PLT_BITS_PER_LONG - 1 - (h #endif #ifndef GENMASK_ULL #define GENMASK_ULL(h, l) \ (((~0ULL) - (1ULL << (l)) + 1) & \ -(~0ULL >> (BITS_PER_LONG_LONG - 1 - (h +(~0ULL >> (PLT_BITS_PER_LONG_LONG - 1 - (h #endif #endif /* _ROC_BITS_H_ */ diff --git a/drivers/common/cnxk/roc_ie_ot.h b/drivers/common/cnxk/roc_ie_ot.h index 1420e3d586..2d94dd3f81 100644 --- a/drivers/common/cnxk/roc_ie_ot.h +++ b/drivers/common/cnxk/roc_ie_ot.h @@ -168,8 +168,8 @@ roc_ie_ot_ucc_is_success(uint8_t ucc) /* u64 array size to fit anti replay window bits */ #define ROC_AR_WINBITS_SZ \ - (PLT_ALIGN_CEIL(ROC_AR_WIN_SIZE_MAX, BITS_PER_LONG_LONG) / \ -BITS_PER_LONG_LONG) + (PLT_ALIGN_CEIL(ROC_AR_WIN_SIZE_MAX, PLT_BITS_PER_LONG_LONG) / \ +PLT_BITS_PER_LONG_LONG) #define ROC_IPSEC_ERR_RING_MAX_ENTRY 65536 diff --git a/drivers/common/cnxk/roc_ie_ot_tls.h b/drivers/common/cnxk/roc_ie_ot_tls.h index 2d6a290d9b..5df9c98b00 100644 --- a/drivers/common/cnxk/roc_ie_ot_tls.h +++ b/drivers/common/cnxk/roc_ie_ot_tls.h @@ -13,8 +13,9 @@ #define ROC_IE_OT_TLS_LOG_MIN_AR_WIN_SIZE_M1 5 /* u64 array size to fit anti replay window bits */ -#define ROC_IE_OT_TLS_AR_WINBITS_SZ \ - (PLT_ALIGN_CEIL(ROC_IE_OT_TLS_AR_WIN_SIZE_MAX, BITS_PER_LONG_LONG) / BITS_PER_LONG_LONG) +#define ROC_IE_OT_TLS_AR_WINBITS_SZ \ + (PLT_ALIGN_CEIL(ROC_IE_OT_TLS_AR_WIN_SIZE_MAX, PLT_BITS_PER_LONG_LONG) / \ + PLT_BITS_PER_LONG_LONG) /* CN10K TLS opcodes */ #define ROC_IE_OT_TLS_MAJOR_OP_RECORD_ENC 0x16UL diff --git a/drivers/common/cnxk/roc_platform.h b/drivers/common/cnxk/roc_platform.h index df4f88f288..6abbc672cc 100644 --- a/drivers/common/cnxk/roc_platform.h +++ b/drivers/common/cnxk/roc_platform.h @@ -58,6 +58,8 @@ #define PLT_ALIGN RTE_ALIGN #define PLT_ALIGN_MUL_CEIL RTE_ALIGN_MUL_CEIL #define PLT_MODEL_MZ_NAME "roc_model_mz" +#define PLT_BITS_PER_LONG RTE_BITS_PER_LONG +#define PLT_BITS_PER_LONG_LONG RTE_BITS_PER_LONG_LONG #define PLT_CACHE_LINE_SIZE RTE_CACHE_LINE_SIZE #define BITMASK_ULL GENMASK_ULL #define PLT_ALIGN_CEIL RTE_ALIGN_CEIL diff --git a/drivers/common/nfp/nfp_platform.h b/drivers/common/nfp/nfp_platform.h index 0b02fcf1e8..e34781a88d 1006
Re: [RFC 2/3] eal: enhance lock annotations for spinlock and seqlock
On 2024-12-02 13:53, David Marchand wrote:
Convert spinlock (and as a consequence seqlock) to the clang
capability annotations.
Acked-by: Mattias Rönnnblom
Signed-off-by: David Marchand
---
drivers/bus/dpaa/base/qbman/qman.c | 4 ++--
drivers/net/fm10k/fm10k_ethdev.c | 4 ++--
lib/eal/include/generic/rte_spinlock.h | 14 +++---
lib/eal/include/rte_eal_memconfig.h| 4 ++--
lib/eal/include/rte_seqlock.h | 4 ++--
lib/graph/graph_private.h | 4 ++--
lib/vhost/vdpa.c | 2 +-
7 files changed, 18 insertions(+), 18 deletions(-)
diff --git a/drivers/bus/dpaa/base/qbman/qman.c
b/drivers/bus/dpaa/base/qbman/qman.c
index f92b25343a..11fabcaff5 100644
--- a/drivers/bus/dpaa/base/qbman/qman.c
+++ b/drivers/bus/dpaa/base/qbman/qman.c
@@ -45,7 +45,7 @@ static inline int fq_isset(struct qman_fq *fq, u32 mask)
}
static inline void fq_lock(struct qman_fq *fq)
- __rte_exclusive_lock_function(&fq->fqlock)
+ __rte_acquire_capability(&fq->fqlock)
__rte_no_thread_safety_analysis
{
if (fq_isset(fq, QMAN_FQ_FLAG_LOCKED))
@@ -53,7 +53,7 @@ static inline void fq_lock(struct qman_fq *fq)
}
static inline void fq_unlock(struct qman_fq *fq)
-__rte_unlock_function(&fq->fqlock)
+ __rte_release_capability(&fq->fqlock)
__rte_no_thread_safety_analysis
{
if (fq_isset(fq, QMAN_FQ_FLAG_LOCKED))
diff --git a/drivers/net/fm10k/fm10k_ethdev.c b/drivers/net/fm10k/fm10k_ethdev.c
index 7b490bea17..747042d621 100644
--- a/drivers/net/fm10k/fm10k_ethdev.c
+++ b/drivers/net/fm10k/fm10k_ethdev.c
@@ -116,7 +116,7 @@ fm10k_mbx_initlock(struct fm10k_hw *hw)
static void
fm10k_mbx_lock(struct fm10k_hw *hw)
- __rte_exclusive_lock_function(FM10K_DEV_PRIVATE_TO_MBXLOCK(hw->back))
+ __rte_acquire_capability(FM10K_DEV_PRIVATE_TO_MBXLOCK(hw->back))
{
while (!rte_spinlock_trylock(FM10K_DEV_PRIVATE_TO_MBXLOCK(hw->back)))
rte_delay_us(FM10K_MBXLOCK_DELAY_US);
@@ -124,7 +124,7 @@ fm10k_mbx_lock(struct fm10k_hw *hw)
static void
fm10k_mbx_unlock(struct fm10k_hw *hw)
- __rte_unlock_function(FM10K_DEV_PRIVATE_TO_MBXLOCK(hw->back))
+ __rte_release_capability(FM10K_DEV_PRIVATE_TO_MBXLOCK(hw->back))
{
rte_spinlock_unlock(FM10K_DEV_PRIVATE_TO_MBXLOCK(hw->back));
}
diff --git a/lib/eal/include/generic/rte_spinlock.h
b/lib/eal/include/generic/rte_spinlock.h
index c2980601b2..c907d4e45c 100644
--- a/lib/eal/include/generic/rte_spinlock.h
+++ b/lib/eal/include/generic/rte_spinlock.h
@@ -32,7 +32,7 @@ extern "C" {
/**
* The rte_spinlock_t type.
*/
-typedef struct __rte_lockable {
+typedef struct __rte_capability("spinlock") {
volatile RTE_ATOMIC(int) locked; /**< lock status 0 = unlocked, 1 =
locked */
} rte_spinlock_t;
@@ -61,7 +61,7 @@ rte_spinlock_init(rte_spinlock_t *sl)
*/
static inline void
rte_spinlock_lock(rte_spinlock_t *sl)
- __rte_exclusive_lock_function(sl);
+ __rte_acquire_capability(sl);
#ifdef RTE_FORCE_INTRINSICS
static inline void
@@ -87,7 +87,7 @@ rte_spinlock_lock(rte_spinlock_t *sl)
*/
static inline void
rte_spinlock_unlock(rte_spinlock_t *sl)
- __rte_unlock_function(sl);
+ __rte_release_capability(sl);
#ifdef RTE_FORCE_INTRINSICS
static inline void
@@ -109,7 +109,7 @@ rte_spinlock_unlock(rte_spinlock_t *sl)
__rte_warn_unused_result
static inline int
rte_spinlock_trylock(rte_spinlock_t *sl)
- __rte_exclusive_trylock_function(1, sl);
+ __rte_try_acquire_capability(true, sl);
#ifdef RTE_FORCE_INTRINSICS
static inline int
@@ -158,7 +158,7 @@ static inline int rte_tm_supported(void);
*/
static inline void
rte_spinlock_lock_tm(rte_spinlock_t *sl)
- __rte_exclusive_lock_function(sl);
+ __rte_acquire_capability(sl);
/**
* Commit hardware memory transaction or release the spinlock if
@@ -169,7 +169,7 @@ rte_spinlock_lock_tm(rte_spinlock_t *sl)
*/
static inline void
rte_spinlock_unlock_tm(rte_spinlock_t *sl)
- __rte_unlock_function(sl);
+ __rte_release_capability(sl);
/**
* Try to execute critical section in a hardware memory transaction,
@@ -190,7 +190,7 @@ rte_spinlock_unlock_tm(rte_spinlock_t *sl)
__rte_warn_unused_result
static inline int
rte_spinlock_trylock_tm(rte_spinlock_t *sl)
- __rte_exclusive_trylock_function(1, sl);
+ __rte_try_acquire_capability(true, sl);
/**
* The rte_spinlock_recursive_t type.
diff --git a/lib/eal/include/rte_eal_memconfig.h
b/lib/eal/include/rte_eal_memconfig.h
index 0b1d0d4ff0..55d78de334 100644
--- a/lib/eal/include/rte_eal_memconfig.h
+++ b/lib/eal/include/rte_eal_memconfig.h
@@ -132,14 +132,14 @@ rte_mcfg_mempool_write_unlock(void)
*/
void
rte_mcfg_timer_lock(void)
- __rte_exclusive_lock_function(rte_mcfg_timer_get_lock());
+ __rte_acquire_capability(rte_mcfg_timer_get_lock());
/**
Re: [PATCH v6 04/30] app/test: replace packed attributes
On Tue, Nov 26, 2024 at 04:52:15PM -0800, Andre Muezerie wrote: > MSVC struct packing is not compatible with GCC. Replace macro > __rte_packed with __rte_packed_begin to push existing pack value > and set packing to 1-byte and macro __rte_packed_end to restore > the pack value prior to the push. > > Macro __rte_packed_end is deliberately utilized to trigger a > MSVC compiler warning if no existing packing has been pushed allowing > easy identification of locations where the __rte_packed_begin is > missing. > > Signed-off-by: Andre Muezerie > --- Reviewed-by: Tyler Retzlaff
[PATCH] MAINTAINERS: update maintainers for next-net
I will be taking on primary maintainer for this release. Andrew has not been doing maintainer work on this branch so remove him. Signed-off-by: Stephen Hemminger --- MAINTAINERS | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/MAINTAINERS b/MAINTAINERS index 60bdcce543..b5690735b1 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -28,8 +28,8 @@ M: David Marchand T: git://dpdk.org/dpdk Next-net Tree +M: Stephen Hemminger M: Ferruh Yigit -M: Andrew Rybchenko T: git://dpdk.org/next/dpdk-next-net Next-net-brcm Tree -- 2.45.2
Re: [PATCH] lib/lpm: use standard atomic_store_explicit
On Wed, Dec 04, 2024 at 08:20:19AM -0800, Andre Muezerie wrote:
> On Wed, Dec 04, 2024 at 08:56:35AM +0100, David Marchand wrote:
> > Hello Andre,
> >
> > On Wed, Dec 4, 2024 at 3:20 AM Andre Muezerie
> > wrote:
> > >
> > > MSVC issues the warning below:
> > >
> > > ../lib/lpm/rte_lpm.c(297): warning C4013
> > > '__atomic_store' undefined; assuming extern returning int
> > > ../lib/lpm/rte_lpm.c(298): error C2065:
> > > '__ATOMIC_RELAXED': undeclared identifier
> > >
> > > The fix is to use standard atomic_store_explicit() instead of
> > > gcc specific __atomic_store().
> > > atomic_store_explicit() was already being used in other parts
> > > of DPDK and is compatible
> > > with many compilers, including MSVC.
> > >
> > > Signed-off-by: Andre Muezerie
> >
> > With this change, is there anything remaining that blocks this library
> > compilation with MSVC?
> > If not, please update meson.build so that CI can test lpm compilation
> > with MSVC on this patch (and that will detect regressions once
> > merged).
> >
> >
> > --
> > David Marchand
>
> Hi David,
>
> I'm eager to enable lpm to be compiled with MSVC. Even though
> this was the last issue I observed for this lib on my machine,
> lpm depends on hash, which depends on net, which depends on mbuf and
> mbuf is not enabled for MSVC yet.
>
I was a bit curious about this dependency chain and decided to investigate
a bit. The "weak link" in this chain appears to me to be the link between
the hash library and the net library. Within the hash library, I believe
only the thash functionality depends on net, for definitions of the ipv6
headers and address fields.
If we want to break that dependency (temporarily, since net is pretty much
an essential DPDK lib), the following patch should work.
Regards,
/Bruce
diff --git a/lib/hash/meson.build b/lib/hash/meson.build
index e6cb1ebe3b..f9096edd67 100644
--- a/lib/hash/meson.build
+++ b/lib/hash/meson.build
@@ -6,24 +6,34 @@ headers = files(
'rte_hash_crc.h',
'rte_hash.h',
'rte_jhash.h',
-'rte_thash.h',
-'rte_thash_gfni.h',
)
indirect_headers += files(
'rte_crc_arm64.h',
'rte_crc_generic.h',
'rte_crc_sw.h',
'rte_crc_x86.h',
-'rte_thash_x86_gfni.h',
)
sources = files(
'rte_cuckoo_hash.c',
'rte_hash_crc.c',
'rte_fbk_hash.c',
+)
+
+deps = ['rcu']
+
+if dpdk_conf.has('RTE_LIB_NET')
+headers += files(
+'rte_thash.h',
+'rte_thash_gfni.h',
+)
+indirect_headers += files(
+'rte_thash_x86_gfni.h',
+)
+sources += files(
'rte_thash.c',
'rte_thash_gfni.c',
'rte_thash_gf2_poly_math.c',
-)
-
-deps = ['net', 'rcu']
+)
+deps += ['net']
+endif
Re: lib/eal/arm/include/rte_vect.h fails to compile with clang14 for 32bit ARM
Considering this problem further, I don't see a way to avoid the CLANG compiler
error with a function implementation. We would need a macro implementation
similar to CLANGS arm_neon.h. In addition, it may be necessary to provide
separate implementations for CLANG and non-CLANG compilers since the builtins
between the toolchains are different. One way to address this would be keep
the existing function implementation, and add a new macro implementation for
CLANG.
For example, something like:
#if !defined(RTE_CC_CLANG)
#if (defined(RTE_ARCH_ARM) && defined(RTE_ARCH_32)) || \
(defined(RTE_ARCH_ARM64) && RTE_CC_IS_GNU && (GCC_VERSION < 7))
/* NEON intrinsic vcopyq_laneq_u32() is not supported in ARMv7-A(AArch32)
* On AArch64, this intrinsic is supported since GCC version 7.
*/
static inline uint32x4_t
vcopyq_laneq_u32(uint32x4_t a, const int lane_a,
uint32x4_t b, const int lane_b)
{
return vsetq_lane_u32(vgetq_lane_u32(b, lane_b), a, lane_a);
}
#endif
#else
#if defined(RTE_ARCH_ARM) && defined(RTE_ARCH_32)
/* NEON intrinsic vcopyq_laneq_u32() is not supported in ARMv7-A(AArch32)
* On AArch64, this intrinsic is supported
*/
#ifdef LITTLE_ENDIAN
#define vcopyq_laneq_u32(__arg1, __arg2, __arg3, __arg4) __extension__ ({ \
uint32x4_t __ret; \
uint32x4_t __lcl_arg1 = __arg1; \
uint32x4_t __lcl_arg3 = __arg3; \
__ret = vsetq_lane_u32(vgetq_lane_u32(__lcl_arg3, __arg4), __lcl_arg1,
__arg2); \
__ret; \
})
#else
#define __noswap_vsetq_lane_u32(__arg1, __arg2, __arg3) __extension__ ({ \
uint32x4_t __ret; \
uint32_t __lcl_arg1 = __arg1; \
uint32x4_t __lcl_arg2 = __arg2; \
__ret = (uint32x4_t) __builtin_neon_vsetq_lane_i32(__lcl_arg1,
(int32x4_t)__lcl_arg2, __arg3); \
__ret; \
})
#define __noswap_vgetq_lane_u32(__arg1, __arg2) __extension__ ({ \
uint32_t __ret; \
uint32x4_t __lcl_arg1 = __arg1; \
__ret = (uint32_t) __builtin_neon_vgetq_lane_i32((int32x4_t)__lcl_arg1,
__arg2); \
__ret; \
})
#define vcopyq_laneq_u32(__arg1, __arg2, __arg3, __arg4) __extension__ ({ \
uint32x4_t __ret; \
uint32x4_t __lcl_arg1 = __arg1; \
uint32x4_t __lcl_arg3 = __arg3; \
uint32x4_t __rev1; \
uint32x4_t __rev3; \
__rev1 = __builtin_shufflevector(__lcl_arg1, __lcl_arg1, 3, 2, 1, 0); \
__rev3 = __builtin_shufflevector(__lcl_arg3, __lcl_arg3, 3, 2, 1, 0); \
__ret = __noswap_vsetq_lane_u32(__noswap_vgetq_lane_u32(__rev3, __arg4),
__rev1, __arg2); \
__ret = __builtin_shufflevector(__ret, __ret, 3, 2, 1, 0); \
__ret; \
})
#endif
#endif
#endif
NOTE1: I saw no reason the CLANG arm_neon.h AARCH64 macros would not work for
AARCH32, so the macros in this sample implementation are copies CLANG originals
modified for (my) readability. I'm not an attorney, but if used, it may be
necessary to include the banner from the CLANG arm_neon.h.
NOTE2: While I can build the CLANG ARM implementation, I lack the hardware to
test it.
Regards,
Roger
On 12/3/24 7:37 PM, Roger Melton (rmelton) wrote:
After looking at this a bit closer today, I realize that my assertion that
CLANG14 does support vcopyq_laneq_u32() for 32bit ARM was incorrect. It does
not. The reason that disabling the implementation in rte_vect.h works for our
clang builds is that we do not build the l3fwd app nor the ixgbe PMD for our
application, and they are the only libraries that reference that function.
The clang compile errors appear to be related to how clang handles compile time
constants, but I'm am again unsure how to resolve them in a way that would work
for both GNU and clang.
Any suggestions?
Regards,
Roger
On 12/2/24 8:26 PM, Ruifeng Wang wrote:
+Arm folks.
From: Roger Melton (rmelton)
Date: Tuesday, December 3, 2024 at 3:39 AM
To: dev@dpdk.org ,
Ruifeng Wang
Subject: lib/eal/arm/include/rte_vect.h fails to compile with clang14 for 32bit
ARM
Hey folks,
We are building DPDK with clang14 for a 32bit armv8-a based CPU and ran into a
compile error with the following from lib/eal/arm/include/rte_vect.h:
#if (defined(RTE_ARCH_ARM) && defined(RTE_ARCH_32)) || \
(defined(RTE_ARCH_ARM64) &&
RTE_CC_IS_GNU &&
(GCC_VERSION <
7))
/* NEON intrinsic vcopyq_laneq_u32() is not supported in ARMv7-A(AArch32)
* On AArch64, this intrinsic is supported since GCC version 7.
*/
static inline uint32x4_t
vcopyq_laneq_u32(uint32x4_t
a, const int lane_a,
uint32x4_t b, const int lane_b)
{
return vsetq_lane_u32(vgetq_lane_u32(b, lane_b), a, lane_a);
}
#endif
clang14 compile fails as follows:
In file included from
../../../../../../cisco-dpdk-upstream-arm-clang-fixes.git/lib/eal/common/eal_common_options.c:36:
../../../../../../cisco-dpdk-upstream-arm-clang-fixes.git/lib/eal/arm/include/rte_ve
Re: [PATCH] lib/lpm: use standard atomic_store_explicit
On Wed, Dec 04, 2024 at 04:52:43PM +, Bruce Richardson wrote:
> On Wed, Dec 04, 2024 at 08:20:19AM -0800, Andre Muezerie wrote:
> > On Wed, Dec 04, 2024 at 08:56:35AM +0100, David Marchand wrote:
> > > Hello Andre,
> > >
> > > On Wed, Dec 4, 2024 at 3:20 AM Andre Muezerie
> > > wrote:
> > > >
> > > > MSVC issues the warning below:
> > > >
> > > > ../lib/lpm/rte_lpm.c(297): warning C4013
> > > > '__atomic_store' undefined; assuming extern returning int
> > > > ../lib/lpm/rte_lpm.c(298): error C2065:
> > > > '__ATOMIC_RELAXED': undeclared identifier
> > > >
> > > > The fix is to use standard atomic_store_explicit() instead of
> > > > gcc specific __atomic_store().
> > > > atomic_store_explicit() was already being used in other parts
> > > > of DPDK and is compatible
> > > > with many compilers, including MSVC.
> > > >
> > > > Signed-off-by: Andre Muezerie
> > >
> > > With this change, is there anything remaining that blocks this library
> > > compilation with MSVC?
> > > If not, please update meson.build so that CI can test lpm compilation
> > > with MSVC on this patch (and that will detect regressions once
> > > merged).
> > >
> > >
> > > --
> > > David Marchand
> >
> > Hi David,
> >
> > I'm eager to enable lpm to be compiled with MSVC. Even though
> > this was the last issue I observed for this lib on my machine,
> > lpm depends on hash, which depends on net, which depends on mbuf and
> > mbuf is not enabled for MSVC yet.
> >
> I was a bit curious about this dependency chain and decided to investigate
> a bit. The "weak link" in this chain appears to me to be the link between
> the hash library and the net library. Within the hash library, I believe
> only the thash functionality depends on net, for definitions of the ipv6
> headers and address fields.
>
> If we want to break that dependency (temporarily, since net is pretty much
> an essential DPDK lib), the following patch should work.
>
> Regards,
> /Bruce
>
> diff --git a/lib/hash/meson.build b/lib/hash/meson.build
> index e6cb1ebe3b..f9096edd67 100644
> --- a/lib/hash/meson.build
> +++ b/lib/hash/meson.build
> @@ -6,24 +6,34 @@ headers = files(
> 'rte_hash_crc.h',
> 'rte_hash.h',
> 'rte_jhash.h',
> -'rte_thash.h',
> -'rte_thash_gfni.h',
> )
> indirect_headers += files(
> 'rte_crc_arm64.h',
> 'rte_crc_generic.h',
> 'rte_crc_sw.h',
> 'rte_crc_x86.h',
> -'rte_thash_x86_gfni.h',
> )
>
> sources = files(
> 'rte_cuckoo_hash.c',
> 'rte_hash_crc.c',
> 'rte_fbk_hash.c',
> +)
> +
> +deps = ['rcu']
> +
> +if dpdk_conf.has('RTE_LIB_NET')
> +headers += files(
> +'rte_thash.h',
> +'rte_thash_gfni.h',
> +)
> +indirect_headers += files(
> +'rte_thash_x86_gfni.h',
> +)
> +sources += files(
> 'rte_thash.c',
> 'rte_thash_gfni.c',
> 'rte_thash_gf2_poly_math.c',
> -)
> -
> -deps = ['net', 'rcu']
> +)
> +deps += ['net']
> +endif
That's a great suggestion. Unfortunately hash also directly depends on
rcu, which is also not yet enabled for MSVC due to pending reviews.
Regards,
Andre Muezerie
[PATCH 0/6] eliminate dependency on non-portable __SIZEOF_LONG__
Macro __SIZEOF_LONG__ is not standardized and MSVC does not define it. Therefore the errors below are seen with MSVC: ../lib/mldev/mldev_utils_scalar.c(465): error C2065: '__SIZEOF_LONG__': undeclared identifier ../lib/mldev/mldev_utils_scalar.c(478): error C2051: case expression not constant ../lib/mldev/mldev_utils_scalar_bfloat16.c(33): error C2065: '__SIZEOF_LONG__': undeclared identifier ../lib/mldev/mldev_utils_scalar_bfloat16.c(49): error C2051: case expression not constant Turns out that the places where __SIZEOF_LONG__ is currently being used can equaly well use sizeof(long) instead. Andre Muezerie (6): drivers/bus: eliminate dependency on non-portable __SIZEOF_LONG__ drivers/common: eliminate dependency on non-portable __SIZEOF_LONG__ drivers/dma: eliminate dependency on non-portable __SIZEOF_LONG__ drivers/net: eliminate dependency on non-portable __SIZEOF_LONG__ drivers/raw: eliminate dependency on non-portable __SIZEOF_LONG__ lib/mldev: eliminate dependency on non-portable __SIZEOF_LONG__ drivers/bus/fslmc/mc/fsl_mc_cmd.h| 2 +- drivers/common/cnxk/roc_bits.h | 4 ++-- drivers/common/nfp/nfp_platform.h| 4 ++-- drivers/dma/dpaa/dpaa_qdma.h | 2 +- drivers/dma/hisilicon/hisi_dmadev.h | 2 +- drivers/net/ena/base/ena_plat_dpdk.h | 4 ++-- drivers/net/hns3/hns3_ethdev.h | 2 +- drivers/raw/ifpga/base/opae_osdep.h | 4 ++-- lib/mldev/mldev_utils_scalar.h | 2 +- 9 files changed, 13 insertions(+), 13 deletions(-) -- 2.47.0.vfs.0.3
[PATCH 1/6] drivers/bus: eliminate dependency on non-portable __SIZEOF_LONG__
Macro __SIZEOF_LONG__ is not standardized and MSVC does not define it. Therefore the errors below are seen with MSVC: ../lib/mldev/mldev_utils_scalar.c(465): error C2065: '__SIZEOF_LONG__': undeclared identifier ../lib/mldev/mldev_utils_scalar.c(478): error C2051: case expression not constant ../lib/mldev/mldev_utils_scalar_bfloat16.c(33): error C2065: '__SIZEOF_LONG__': undeclared identifier ../lib/mldev/mldev_utils_scalar_bfloat16.c(49): error C2051: case expression not constant Turns out that the places where __SIZEOF_LONG__ is currently being used can equaly well use sizeof(long) instead. Signed-off-by: Andre Muezerie --- drivers/bus/fslmc/mc/fsl_mc_cmd.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/bus/fslmc/mc/fsl_mc_cmd.h b/drivers/bus/fslmc/mc/fsl_mc_cmd.h index a768774c89..10804e6c5d 100644 --- a/drivers/bus/fslmc/mc/fsl_mc_cmd.h +++ b/drivers/bus/fslmc/mc/fsl_mc_cmd.h @@ -29,7 +29,7 @@ #define le32_to_cpurte_le_to_cpu_32 #define le16_to_cpurte_le_to_cpu_16 -#define BITS_PER_LONG (__SIZEOF_LONG__ * 8) +#define BITS_PER_LONG (sizeof(long) * 8) #define GENMASK(h, l) \ (((~0UL) << (l)) & (~0UL >> (BITS_PER_LONG - 1 - (h -- 2.47.0.vfs.0.3
[PATCH 3/6] drivers/dma: eliminate dependency on non-portable __SIZEOF_LONG__
Macro __SIZEOF_LONG__ is not standardized and MSVC does not define it. Therefore the errors below are seen with MSVC: ../lib/mldev/mldev_utils_scalar.c(465): error C2065: '__SIZEOF_LONG__': undeclared identifier ../lib/mldev/mldev_utils_scalar.c(478): error C2051: case expression not constant ../lib/mldev/mldev_utils_scalar_bfloat16.c(33): error C2065: '__SIZEOF_LONG__': undeclared identifier ../lib/mldev/mldev_utils_scalar_bfloat16.c(49): error C2051: case expression not constant Turns out that the places where __SIZEOF_LONG__ is currently being used can equaly well use sizeof(long) instead. Signed-off-by: Andre Muezerie --- drivers/dma/dpaa/dpaa_qdma.h| 2 +- drivers/dma/hisilicon/hisi_dmadev.h | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/dma/dpaa/dpaa_qdma.h b/drivers/dma/dpaa/dpaa_qdma.h index 579483ac34..3736c0d431 100644 --- a/drivers/dma/dpaa/dpaa_qdma.h +++ b/drivers/dma/dpaa/dpaa_qdma.h @@ -14,7 +14,7 @@ #define RETRIES5 #ifndef GENMASK -#define BITS_PER_LONG (__SIZEOF_LONG__ * 8) +#define BITS_PER_LONG (sizeof(long) * 8) #define GENMASK(h, l) \ (((~0UL) << (l)) & (~0UL >> (BITS_PER_LONG - 1 - (h #endif diff --git a/drivers/dma/hisilicon/hisi_dmadev.h b/drivers/dma/hisilicon/hisi_dmadev.h index 786fe3cc0e..777b9dd704 100644 --- a/drivers/dma/hisilicon/hisi_dmadev.h +++ b/drivers/dma/hisilicon/hisi_dmadev.h @@ -12,7 +12,7 @@ #include #define BIT(x) (1ul << (x)) -#define BITS_PER_LONG (__SIZEOF_LONG__ * 8) +#define BITS_PER_LONG (sizeof(long) * 8) #define GENMASK(h, l) \ (((~0UL) << (l)) & (~0UL >> (BITS_PER_LONG - 1 - (h #define BF_SHF(x) rte_bsf64(x) -- 2.47.0.vfs.0.3
[PATCH 2/6] drivers/common: eliminate dependency on non-portable __SIZEOF_LONG__
Macro __SIZEOF_LONG__ is not standardized and MSVC does not define it. Therefore the errors below are seen with MSVC: ../lib/mldev/mldev_utils_scalar.c(465): error C2065: '__SIZEOF_LONG__': undeclared identifier ../lib/mldev/mldev_utils_scalar.c(478): error C2051: case expression not constant ../lib/mldev/mldev_utils_scalar_bfloat16.c(33): error C2065: '__SIZEOF_LONG__': undeclared identifier ../lib/mldev/mldev_utils_scalar_bfloat16.c(49): error C2051: case expression not constant Turns out that the places where __SIZEOF_LONG__ is currently being used can equaly well use sizeof(long) instead. Signed-off-by: Andre Muezerie --- drivers/common/cnxk/roc_bits.h| 4 ++-- drivers/common/nfp/nfp_platform.h | 4 ++-- 2 files changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/common/cnxk/roc_bits.h b/drivers/common/cnxk/roc_bits.h index 11216d9d63..aa4944ae7f 100644 --- a/drivers/common/cnxk/roc_bits.h +++ b/drivers/common/cnxk/roc_bits.h @@ -14,10 +14,10 @@ #endif #ifndef BITS_PER_LONG -#define BITS_PER_LONG (__SIZEOF_LONG__ * 8) +#define BITS_PER_LONG (sizeof(long) * 8) #endif #ifndef BITS_PER_LONG_LONG -#define BITS_PER_LONG_LONG (__SIZEOF_LONG_LONG__ * 8) +#define BITS_PER_LONG_LONG (sizeof(long long) * 8) #endif #ifndef GENMASK diff --git a/drivers/common/nfp/nfp_platform.h b/drivers/common/nfp/nfp_platform.h index 0b02fcf1e8..27792aca97 100644 --- a/drivers/common/nfp/nfp_platform.h +++ b/drivers/common/nfp/nfp_platform.h @@ -14,8 +14,8 @@ #define DMA_BIT_MASK(n)((1ULL << (n)) - 1) -#define BITS_PER_LONG (__SIZEOF_LONG__ * 8) -#define BITS_PER_LONG_LONG (__SIZEOF_LONG_LONG__ * 8) +#define BITS_PER_LONG (sizeof(long) * 8) +#define BITS_PER_LONG_LONG (sizeof(long long) * 8) #define GENMASK(h, l) \ ((~0UL << (l)) & (~0UL >> (BITS_PER_LONG - (h) - 1))) -- 2.47.0.vfs.0.3
[PATCH 6/6] lib/mldev: eliminate dependency on non-portable __SIZEOF_LONG__
Macro __SIZEOF_LONG__ is not standardized and MSVC does not define it. Therefore the errors below are seen with MSVC: ../lib/mldev/mldev_utils_scalar.c(465): error C2065: '__SIZEOF_LONG__': undeclared identifier ../lib/mldev/mldev_utils_scalar.c(478): error C2051: case expression not constant ../lib/mldev/mldev_utils_scalar_bfloat16.c(33): error C2065: '__SIZEOF_LONG__': undeclared identifier ../lib/mldev/mldev_utils_scalar_bfloat16.c(49): error C2051: case expression not constant Turns out that the places where __SIZEOF_LONG__ is currently being used can equaly well use sizeof(long) instead. Signed-off-by: Andre Muezerie --- lib/mldev/mldev_utils_scalar.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/lib/mldev/mldev_utils_scalar.h b/lib/mldev/mldev_utils_scalar.h index 57e66ddb60..d12e358fb5 100644 --- a/lib/mldev/mldev_utils_scalar.h +++ b/lib/mldev/mldev_utils_scalar.h @@ -13,7 +13,7 @@ #endif #ifndef BITS_PER_LONG -#define BITS_PER_LONG (__SIZEOF_LONG__ * 8) +#define BITS_PER_LONG (sizeof(long) * 8) #endif #ifndef GENMASK_U32 -- 2.47.0.vfs.0.3
[PATCH 5/6] drivers/raw: eliminate dependency on non-portable __SIZEOF_LONG__
Macro __SIZEOF_LONG__ is not standardized and MSVC does not define it.
Therefore the errors below are seen with MSVC:
../lib/mldev/mldev_utils_scalar.c(465): error C2065:
'__SIZEOF_LONG__': undeclared identifier
../lib/mldev/mldev_utils_scalar.c(478): error C2051:
case expression not constant
../lib/mldev/mldev_utils_scalar_bfloat16.c(33): error C2065:
'__SIZEOF_LONG__': undeclared identifier
../lib/mldev/mldev_utils_scalar_bfloat16.c(49): error C2051:
case expression not constant
Turns out that the places where __SIZEOF_LONG__ is currently
being used can equaly well use sizeof(long) instead.
Signed-off-by: Andre Muezerie
---
drivers/raw/ifpga/base/opae_osdep.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/raw/ifpga/base/opae_osdep.h
b/drivers/raw/ifpga/base/opae_osdep.h
index cb780b1fed..bb8d2a1dd6 100644
--- a/drivers/raw/ifpga/base/opae_osdep.h
+++ b/drivers/raw/ifpga/base/opae_osdep.h
@@ -31,10 +31,10 @@ struct uuid {
#ifndef LINUX_MACROS
#ifndef BITS_PER_LONG
-#define BITS_PER_LONG (__SIZEOF_LONG__ * 8)
+#define BITS_PER_LONG (sizeof(long) * 8)
#endif
#ifndef BITS_PER_LONG_LONG
-#define BITS_PER_LONG_LONG (__SIZEOF_LONG_LONG__ * 8)
+#define BITS_PER_LONG_LONG (sizeof(long long) * 8)
#endif
#ifndef BIT
#define BIT(a) (1UL << (a))
--
2.47.0.vfs.0.3
[PATCH 4/6] drivers/net: eliminate dependency on non-portable __SIZEOF_LONG__
Macro __SIZEOF_LONG__ is not standardized and MSVC does not define it. Therefore the errors below are seen with MSVC: ../lib/mldev/mldev_utils_scalar.c(465): error C2065: '__SIZEOF_LONG__': undeclared identifier ../lib/mldev/mldev_utils_scalar.c(478): error C2051: case expression not constant ../lib/mldev/mldev_utils_scalar_bfloat16.c(33): error C2065: '__SIZEOF_LONG__': undeclared identifier ../lib/mldev/mldev_utils_scalar_bfloat16.c(49): error C2051: case expression not constant Turns out that the places where __SIZEOF_LONG__ is currently being used can equaly well use sizeof(long) instead. Signed-off-by: Andre Muezerie --- drivers/net/ena/base/ena_plat_dpdk.h | 4 ++-- drivers/net/hns3/hns3_ethdev.h | 2 +- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/net/ena/base/ena_plat_dpdk.h b/drivers/net/ena/base/ena_plat_dpdk.h index 1121460470..24e0435ac1 100644 --- a/drivers/net/ena/base/ena_plat_dpdk.h +++ b/drivers/net/ena/base/ena_plat_dpdk.h @@ -97,11 +97,11 @@ extern int ena_logtype_com; #define ENA_MIN16(x, y) ENA_MIN_T(uint16_t, (x), (y)) #define ENA_MIN8(x, y) ENA_MIN_T(uint8_t, (x), (y)) -#define BITS_PER_LONG_LONG (__SIZEOF_LONG_LONG__ * 8) +#define BITS_PER_LONG_LONG (sizeof(long long) * 8) #define U64_C(x) x ## ULL #define BIT(nr)RTE_BIT32(nr) #define BIT64(nr) RTE_BIT64(nr) -#define BITS_PER_LONG (__SIZEOF_LONG__ * 8) +#define BITS_PER_LONG (sizeof(long) * 8) #define GENMASK(h, l) (((~0UL) << (l)) & (~0UL >> (BITS_PER_LONG - 1 - (h #define GENMASK_ULL(h, l) (((~0ULL) - (1ULL << (l)) + 1) &\ (~0ULL >> (BITS_PER_LONG_LONG - 1 - (h diff --git a/drivers/net/hns3/hns3_ethdev.h b/drivers/net/hns3/hns3_ethdev.h index 7824503bb8..207a92f832 100644 --- a/drivers/net/hns3/hns3_ethdev.h +++ b/drivers/net/hns3/hns3_ethdev.h @@ -952,7 +952,7 @@ static inline struct hns3_vf *HNS3_DEV_HW_TO_VF(struct hns3_hw *hw) #define BIT_ULL(x) (1ULL << (x)) -#define BITS_PER_LONG (__SIZEOF_LONG__ * 8) +#define BITS_PER_LONG (sizeof(long) * 8) #define GENMASK(h, l) \ (((~0UL) << (l)) & (~0UL >> (BITS_PER_LONG - 1 - (h -- 2.47.0.vfs.0.3
Re: rte_mempool_create fails with --no-huge
Hi Alipour, It looks suspicious that on the host you don't see logs about loaded drivers, like these ones that you see inside the VM: > 2024-12-03 19:32:36.642042 EAL: open shared lib > /usr/lib/dpdk/pmds-24.0/librte_net_fm10k.so.24.0 > 2024-12-03 19:32:36.642266 EAL: pmd.net.fm10k.init log level changed from > disabled to notice > 2024-12-03 19:32:36.642279 EAL: pmd.net.fm10k.driver log level changed from > disabled to notice > 2024-12-03 19:32:36.642285 EAL: open shared lib > /usr/lib/dpdk/pmds-24.0/librte_net_qdma.so.24.0 > 2024-12-03 19:32:36.642581 EAL: open shared lib > /usr/lib/dpdk/pmds-24.0/librte_net_vhost.so > 2024-12-03 19:32:36.643201 EAL: lib.dmadev log level changed from disabled > to info > 2024-12-03 19:32:36.643264 EAL: Registered [vdpa] device class. Can it be that DPDK on the host does not see shared libraries, e.g. it is not installed in the system and LD_LIBRARY_PATH is not set to shared library location? Then mempool driver would just not be loaded to create a mempool.
[PATCH v2 1/6] drivers/bus: eliminate dependency on non-portable __SIZEOF_LONG__
Macro __SIZEOF_LONG__ is not standardized and MSVC does not define it. Therefore the errors below are seen with MSVC: ../lib/mldev/mldev_utils_scalar.c(465): error C2065: '__SIZEOF_LONG__': undeclared identifier ../lib/mldev/mldev_utils_scalar.c(478): error C2051: case expression not constant ../lib/mldev/mldev_utils_scalar_bfloat16.c(33): error C2065: '__SIZEOF_LONG__': undeclared identifier ../lib/mldev/mldev_utils_scalar_bfloat16.c(49): error C2051: case expression not constant Turns out that the places where __SIZEOF_LONG__ is currently being used can equally well use sizeof(long) instead. Signed-off-by: Andre Muezerie --- drivers/bus/fslmc/mc/fsl_mc_cmd.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/bus/fslmc/mc/fsl_mc_cmd.h b/drivers/bus/fslmc/mc/fsl_mc_cmd.h index a768774c89..10804e6c5d 100644 --- a/drivers/bus/fslmc/mc/fsl_mc_cmd.h +++ b/drivers/bus/fslmc/mc/fsl_mc_cmd.h @@ -29,7 +29,7 @@ #define le32_to_cpurte_le_to_cpu_32 #define le16_to_cpurte_le_to_cpu_16 -#define BITS_PER_LONG (__SIZEOF_LONG__ * 8) +#define BITS_PER_LONG (sizeof(long) * 8) #define GENMASK(h, l) \ (((~0UL) << (l)) & (~0UL >> (BITS_PER_LONG - 1 - (h -- 2.47.0.vfs.0.3
[PATCH v2 0/6] eliminate dependency on non-portable __SIZEOF_LONG__
Macro __SIZEOF_LONG__ is not standardized and MSVC does not define it. Therefore the errors below are seen with MSVC: ../lib/mldev/mldev_utils_scalar.c(465): error C2065: '__SIZEOF_LONG__': undeclared identifier ../lib/mldev/mldev_utils_scalar.c(478): error C2051: case expression not constant ../lib/mldev/mldev_utils_scalar_bfloat16.c(33): error C2065: '__SIZEOF_LONG__': undeclared identifier ../lib/mldev/mldev_utils_scalar_bfloat16.c(49): error C2051: case expression not constant Turns out that the places where __SIZEOF_LONG__ is currently being used can equally well use sizeof(long) instead. v2: * fixed typo in commit message Andre Muezerie (6): drivers/bus: eliminate dependency on non-portable __SIZEOF_LONG__ drivers/common: eliminate dependency on non-portable __SIZEOF_LONG__ drivers/dma: eliminate dependency on non-portable __SIZEOF_LONG__ drivers/net: eliminate dependency on non-portable __SIZEOF_LONG__ drivers/raw: eliminate dependency on non-portable __SIZEOF_LONG__ lib/mldev: eliminate dependency on non-portable __SIZEOF_LONG__ drivers/bus/fslmc/mc/fsl_mc_cmd.h| 2 +- drivers/common/cnxk/roc_bits.h | 4 ++-- drivers/common/nfp/nfp_platform.h| 4 ++-- drivers/dma/dpaa/dpaa_qdma.h | 2 +- drivers/dma/hisilicon/hisi_dmadev.h | 2 +- drivers/net/ena/base/ena_plat_dpdk.h | 4 ++-- drivers/net/hns3/hns3_ethdev.h | 2 +- drivers/raw/ifpga/base/opae_osdep.h | 4 ++-- lib/mldev/mldev_utils_scalar.h | 2 +- 9 files changed, 13 insertions(+), 13 deletions(-) -- 2.47.0.vfs.0.3
[PATCH v2 2/6] drivers/common: eliminate dependency on non-portable __SIZEOF_LONG__
Macro __SIZEOF_LONG__ is not standardized and MSVC does not define it. Therefore the errors below are seen with MSVC: ../lib/mldev/mldev_utils_scalar.c(465): error C2065: '__SIZEOF_LONG__': undeclared identifier ../lib/mldev/mldev_utils_scalar.c(478): error C2051: case expression not constant ../lib/mldev/mldev_utils_scalar_bfloat16.c(33): error C2065: '__SIZEOF_LONG__': undeclared identifier ../lib/mldev/mldev_utils_scalar_bfloat16.c(49): error C2051: case expression not constant Turns out that the places where __SIZEOF_LONG__ is currently being used can equally well use sizeof(long) instead. Signed-off-by: Andre Muezerie --- drivers/common/cnxk/roc_bits.h| 4 ++-- drivers/common/nfp/nfp_platform.h | 4 ++-- 2 files changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/common/cnxk/roc_bits.h b/drivers/common/cnxk/roc_bits.h index 11216d9d63..aa4944ae7f 100644 --- a/drivers/common/cnxk/roc_bits.h +++ b/drivers/common/cnxk/roc_bits.h @@ -14,10 +14,10 @@ #endif #ifndef BITS_PER_LONG -#define BITS_PER_LONG (__SIZEOF_LONG__ * 8) +#define BITS_PER_LONG (sizeof(long) * 8) #endif #ifndef BITS_PER_LONG_LONG -#define BITS_PER_LONG_LONG (__SIZEOF_LONG_LONG__ * 8) +#define BITS_PER_LONG_LONG (sizeof(long long) * 8) #endif #ifndef GENMASK diff --git a/drivers/common/nfp/nfp_platform.h b/drivers/common/nfp/nfp_platform.h index 0b02fcf1e8..27792aca97 100644 --- a/drivers/common/nfp/nfp_platform.h +++ b/drivers/common/nfp/nfp_platform.h @@ -14,8 +14,8 @@ #define DMA_BIT_MASK(n)((1ULL << (n)) - 1) -#define BITS_PER_LONG (__SIZEOF_LONG__ * 8) -#define BITS_PER_LONG_LONG (__SIZEOF_LONG_LONG__ * 8) +#define BITS_PER_LONG (sizeof(long) * 8) +#define BITS_PER_LONG_LONG (sizeof(long long) * 8) #define GENMASK(h, l) \ ((~0UL << (l)) & (~0UL >> (BITS_PER_LONG - (h) - 1))) -- 2.47.0.vfs.0.3
[PATCH v2 6/6] lib/mldev: eliminate dependency on non-portable __SIZEOF_LONG__
Macro __SIZEOF_LONG__ is not standardized and MSVC does not define it. Therefore the errors below are seen with MSVC: ../lib/mldev/mldev_utils_scalar.c(465): error C2065: '__SIZEOF_LONG__': undeclared identifier ../lib/mldev/mldev_utils_scalar.c(478): error C2051: case expression not constant ../lib/mldev/mldev_utils_scalar_bfloat16.c(33): error C2065: '__SIZEOF_LONG__': undeclared identifier ../lib/mldev/mldev_utils_scalar_bfloat16.c(49): error C2051: case expression not constant Turns out that the places where __SIZEOF_LONG__ is currently being used can equally well use sizeof(long) instead. Signed-off-by: Andre Muezerie --- lib/mldev/mldev_utils_scalar.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/lib/mldev/mldev_utils_scalar.h b/lib/mldev/mldev_utils_scalar.h index 57e66ddb60..d12e358fb5 100644 --- a/lib/mldev/mldev_utils_scalar.h +++ b/lib/mldev/mldev_utils_scalar.h @@ -13,7 +13,7 @@ #endif #ifndef BITS_PER_LONG -#define BITS_PER_LONG (__SIZEOF_LONG__ * 8) +#define BITS_PER_LONG (sizeof(long) * 8) #endif #ifndef GENMASK_U32 -- 2.47.0.vfs.0.3
[PATCH v2 5/6] drivers/raw: eliminate dependency on non-portable __SIZEOF_LONG__
Macro __SIZEOF_LONG__ is not standardized and MSVC does not define it.
Therefore the errors below are seen with MSVC:
../lib/mldev/mldev_utils_scalar.c(465): error C2065:
'__SIZEOF_LONG__': undeclared identifier
../lib/mldev/mldev_utils_scalar.c(478): error C2051:
case expression not constant
../lib/mldev/mldev_utils_scalar_bfloat16.c(33): error C2065:
'__SIZEOF_LONG__': undeclared identifier
../lib/mldev/mldev_utils_scalar_bfloat16.c(49): error C2051:
case expression not constant
Turns out that the places where __SIZEOF_LONG__ is currently
being used can equally well use sizeof(long) instead.
Signed-off-by: Andre Muezerie
---
drivers/raw/ifpga/base/opae_osdep.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/raw/ifpga/base/opae_osdep.h
b/drivers/raw/ifpga/base/opae_osdep.h
index cb780b1fed..bb8d2a1dd6 100644
--- a/drivers/raw/ifpga/base/opae_osdep.h
+++ b/drivers/raw/ifpga/base/opae_osdep.h
@@ -31,10 +31,10 @@ struct uuid {
#ifndef LINUX_MACROS
#ifndef BITS_PER_LONG
-#define BITS_PER_LONG (__SIZEOF_LONG__ * 8)
+#define BITS_PER_LONG (sizeof(long) * 8)
#endif
#ifndef BITS_PER_LONG_LONG
-#define BITS_PER_LONG_LONG (__SIZEOF_LONG_LONG__ * 8)
+#define BITS_PER_LONG_LONG (sizeof(long long) * 8)
#endif
#ifndef BIT
#define BIT(a) (1UL << (a))
--
2.47.0.vfs.0.3
[PATCH v2 4/6] drivers/net: eliminate dependency on non-portable __SIZEOF_LONG__
Macro __SIZEOF_LONG__ is not standardized and MSVC does not define it. Therefore the errors below are seen with MSVC: ../lib/mldev/mldev_utils_scalar.c(465): error C2065: '__SIZEOF_LONG__': undeclared identifier ../lib/mldev/mldev_utils_scalar.c(478): error C2051: case expression not constant ../lib/mldev/mldev_utils_scalar_bfloat16.c(33): error C2065: '__SIZEOF_LONG__': undeclared identifier ../lib/mldev/mldev_utils_scalar_bfloat16.c(49): error C2051: case expression not constant Turns out that the places where __SIZEOF_LONG__ is currently being used can equally well use sizeof(long) instead. Signed-off-by: Andre Muezerie --- drivers/net/ena/base/ena_plat_dpdk.h | 4 ++-- drivers/net/hns3/hns3_ethdev.h | 2 +- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/net/ena/base/ena_plat_dpdk.h b/drivers/net/ena/base/ena_plat_dpdk.h index 1121460470..24e0435ac1 100644 --- a/drivers/net/ena/base/ena_plat_dpdk.h +++ b/drivers/net/ena/base/ena_plat_dpdk.h @@ -97,11 +97,11 @@ extern int ena_logtype_com; #define ENA_MIN16(x, y) ENA_MIN_T(uint16_t, (x), (y)) #define ENA_MIN8(x, y) ENA_MIN_T(uint8_t, (x), (y)) -#define BITS_PER_LONG_LONG (__SIZEOF_LONG_LONG__ * 8) +#define BITS_PER_LONG_LONG (sizeof(long long) * 8) #define U64_C(x) x ## ULL #define BIT(nr)RTE_BIT32(nr) #define BIT64(nr) RTE_BIT64(nr) -#define BITS_PER_LONG (__SIZEOF_LONG__ * 8) +#define BITS_PER_LONG (sizeof(long) * 8) #define GENMASK(h, l) (((~0UL) << (l)) & (~0UL >> (BITS_PER_LONG - 1 - (h #define GENMASK_ULL(h, l) (((~0ULL) - (1ULL << (l)) + 1) &\ (~0ULL >> (BITS_PER_LONG_LONG - 1 - (h diff --git a/drivers/net/hns3/hns3_ethdev.h b/drivers/net/hns3/hns3_ethdev.h index 7824503bb8..207a92f832 100644 --- a/drivers/net/hns3/hns3_ethdev.h +++ b/drivers/net/hns3/hns3_ethdev.h @@ -952,7 +952,7 @@ static inline struct hns3_vf *HNS3_DEV_HW_TO_VF(struct hns3_hw *hw) #define BIT_ULL(x) (1ULL << (x)) -#define BITS_PER_LONG (__SIZEOF_LONG__ * 8) +#define BITS_PER_LONG (sizeof(long) * 8) #define GENMASK(h, l) \ (((~0UL) << (l)) & (~0UL >> (BITS_PER_LONG - 1 - (h -- 2.47.0.vfs.0.3
[PATCH v2 3/6] drivers/dma: eliminate dependency on non-portable __SIZEOF_LONG__
Macro __SIZEOF_LONG__ is not standardized and MSVC does not define it. Therefore the errors below are seen with MSVC: ../lib/mldev/mldev_utils_scalar.c(465): error C2065: '__SIZEOF_LONG__': undeclared identifier ../lib/mldev/mldev_utils_scalar.c(478): error C2051: case expression not constant ../lib/mldev/mldev_utils_scalar_bfloat16.c(33): error C2065: '__SIZEOF_LONG__': undeclared identifier ../lib/mldev/mldev_utils_scalar_bfloat16.c(49): error C2051: case expression not constant Turns out that the places where __SIZEOF_LONG__ is currently being used can equally well use sizeof(long) instead. Signed-off-by: Andre Muezerie --- drivers/dma/dpaa/dpaa_qdma.h| 2 +- drivers/dma/hisilicon/hisi_dmadev.h | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/dma/dpaa/dpaa_qdma.h b/drivers/dma/dpaa/dpaa_qdma.h index 579483ac34..3736c0d431 100644 --- a/drivers/dma/dpaa/dpaa_qdma.h +++ b/drivers/dma/dpaa/dpaa_qdma.h @@ -14,7 +14,7 @@ #define RETRIES5 #ifndef GENMASK -#define BITS_PER_LONG (__SIZEOF_LONG__ * 8) +#define BITS_PER_LONG (sizeof(long) * 8) #define GENMASK(h, l) \ (((~0UL) << (l)) & (~0UL >> (BITS_PER_LONG - 1 - (h #endif diff --git a/drivers/dma/hisilicon/hisi_dmadev.h b/drivers/dma/hisilicon/hisi_dmadev.h index 786fe3cc0e..777b9dd704 100644 --- a/drivers/dma/hisilicon/hisi_dmadev.h +++ b/drivers/dma/hisilicon/hisi_dmadev.h @@ -12,7 +12,7 @@ #include #define BIT(x) (1ul << (x)) -#define BITS_PER_LONG (__SIZEOF_LONG__ * 8) +#define BITS_PER_LONG (sizeof(long) * 8) #define GENMASK(h, l) \ (((~0UL) << (l)) & (~0UL >> (BITS_PER_LONG - 1 - (h #define BF_SHF(x) rte_bsf64(x) -- 2.47.0.vfs.0.3
Re: eal: -n or -r options are ignored when --in-memory is used
Hi Igor, 2024-10-23 02:25 (UTC+0300), Igor Gutorov: > I've noticed an issue of `rte_memory_get_nchannel()` or > `rte_memory_get_nrank()` always returning zero regardless of the -n or > -r options set. > > I think this is due to `--in-memory` forcing `conf->no_shconf = 1` > [1], which leads to `rte_eal_memdevice_init()` never being executed > [2]. > > I do not fully understand the context of the code, but I can submit a > patch that simply removes the `internal_conf->no_shconf == 0` check in > `rte_eal_memory_init()` and so always calls > `rte_eal_memdevice_init()`. Would that be ok or is there a better way? > Alternatively, does `(internal_conf->no_shconf == 0 || > internal_conf->in_memory == 1) && ...` make sense here? Well spotted! Yes, the check seems unneeded. > And one more thing, the 9.1.4 section of the getting started guide > states that the number of memory ranks is auto-detected by default, > but I can't find any code that performs the auto-detection - am I > missing something, or is the documentation wrong here? The doc is clearly wrong. Git says this piece originates from TestPMD documentation, so maybe "auto-detected" refers to some defaults for mempools: https://elixir.bootlin.com/dpdk/v24.11/source/lib/mempool/rte_mempool.c#L93 > > [1]: > https://github.com/DPDK/dpdk/blob/3ee7a3e0e0e0f5a81a4b102a834697bc488fb32f/lib/eal/common/eal_common_options.c#L1815 > [2]: > https://github.com/DPDK/dpdk/blob/3ee7a3e0e0e0f5a81a4b102a834697bc488fb32f/lib/eal/common/eal_common_memory.c#L1103
Re: [PATCH 0/6] eliminate dependency on non-portable __SIZEOF_LONG__
On Wed, 4 Dec 2024 12:09:49 -0800 Andre Muezerie wrote: > Macro __SIZEOF_LONG__ is not standardized and MSVC does not define it. > Therefore the errors below are seen with MSVC: > > ../lib/mldev/mldev_utils_scalar.c(465): error C2065: > '__SIZEOF_LONG__': undeclared identifier > ../lib/mldev/mldev_utils_scalar.c(478): error C2051: > case expression not constant > > ../lib/mldev/mldev_utils_scalar_bfloat16.c(33): error C2065: > '__SIZEOF_LONG__': undeclared identifier > ../lib/mldev/mldev_utils_scalar_bfloat16.c(49): error C2051: > case expression not constant > > Turns out that the places where __SIZEOF_LONG__ is currently > being used can equaly well use sizeof(long) instead. > > Andre Muezerie (6): > drivers/bus: eliminate dependency on non-portable __SIZEOF_LONG__ > drivers/common: eliminate dependency on non-portable __SIZEOF_LONG__ > drivers/dma: eliminate dependency on non-portable __SIZEOF_LONG__ > drivers/net: eliminate dependency on non-portable __SIZEOF_LONG__ > drivers/raw: eliminate dependency on non-portable __SIZEOF_LONG__ > lib/mldev: eliminate dependency on non-portable __SIZEOF_LONG__ > > drivers/bus/fslmc/mc/fsl_mc_cmd.h| 2 +- > drivers/common/cnxk/roc_bits.h | 4 ++-- > drivers/common/nfp/nfp_platform.h| 4 ++-- > drivers/dma/dpaa/dpaa_qdma.h | 2 +- > drivers/dma/hisilicon/hisi_dmadev.h | 2 +- > drivers/net/ena/base/ena_plat_dpdk.h | 4 ++-- > drivers/net/hns3/hns3_ethdev.h | 2 +- > drivers/raw/ifpga/base/opae_osdep.h | 4 ++-- > lib/mldev/mldev_utils_scalar.h | 2 +- > 9 files changed, 13 insertions(+), 13 deletions(-) > > -- BITS_PER_LONG etc should be in rte_common.h not scattered all over these drivers.
Re: eal: -n or -r options are ignored when --in-memory is used
On Thu, 5 Dec 2024 00:50:24 +0300 Dmitry Kozlyuk wrote: > Hi Igor, > > 2024-10-23 02:25 (UTC+0300), Igor Gutorov: > > I've noticed an issue of `rte_memory_get_nchannel()` or > > `rte_memory_get_nrank()` always returning zero regardless of the -n or > > -r options set. > > > > I think this is due to `--in-memory` forcing `conf->no_shconf = 1` > > [1], which leads to `rte_eal_memdevice_init()` never being executed > > [2]. > > > > I do not fully understand the context of the code, but I can submit a > > patch that simply removes the `internal_conf->no_shconf == 0` check in > > `rte_eal_memory_init()` and so always calls > > `rte_eal_memdevice_init()`. Would that be ok or is there a better way? > > Alternatively, does `(internal_conf->no_shconf == 0 || > > internal_conf->in_memory == 1) && ...` make sense here? > > Well spotted! Yes, the check seems unneeded. > > > And one more thing, the 9.1.4 section of the getting started guide > > states that the number of memory ranks is auto-detected by default, > > but I can't find any code that performs the auto-detection - am I > > missing something, or is the documentation wrong here? > > The doc is clearly wrong. > Git says this piece originates from TestPMD documentation, > so maybe "auto-detected" refers to some defaults for mempools: Doc should be reworded to some thing like "if not defined, reasonable default values are used instead". It is difficult to do auto-detection of memory layout optimum spread. The Linux kernel provides no visible API for finding out; and the only way I know is digging into DMI data (see dmidecode). But DMI data is only readable as root, can be wrong, and doesn't really match in a cloud environment.
Re: [RFC 2/5] net/ngbe: fix query handling in xstats_get
On Tue, 8 Oct 2024 08:59:56 -0700
Stephen Hemminger wrote:
> The xstats_get function in this driver did not act the same
> as other drivers when queried. The correct check is to look
> at the requested number of stats and compare it to the available
> stats and if the request is too small, return the correct size.
>
> Bugzilla ID: 1560
> Fixes: 8b433d04adc9 ("net/ngbe: support device xstats")
> Cc: jiawe...@trustnetic.com
>
> Signed-off-by: Stephen Hemminger
This needs to be tested on this hardware before merging.
Re: [RFC 4/5] net/octeontx: fix handling of xstats_get
On Tue, 8 Oct 2024 08:59:58 -0700
Stephen Hemminger wrote:
> The xstats_get function in this driver did not act the same
> as other drivers when queried. The correct check is to look
> at the requested number of stats and compare it to the available
> stats and if the request is too small, return the correct size.
>
> Fixes: 5538990924f2 ("net/octeontx: add basic stats support")
> Cc: jerin.ja...@caviumnetworks.com
> Signed-off-by: Stephen Hemminger
> ---
> drivers/net/octeontx/octeontx_ethdev.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/net/octeontx/octeontx_ethdev.c
> b/drivers/net/octeontx/octeontx_ethdev.c
> index 3b8d717797..51093cc815 100644
> --- a/drivers/net/octeontx/octeontx_ethdev.c
> +++ b/drivers/net/octeontx/octeontx_ethdev.c
> @@ -1016,6 +1016,9 @@ octeontx_dev_xstats_get(struct rte_eth_dev *dev,
> struct octeontx_nic *nic = octeontx_pmd_priv(dev);
>
> PMD_INIT_FUNC_TRACE();
> + if (n < NUM_BGX_XSTAT)
> + return NUM_BGX_XSTAT;
> +
> return octeontx_port_xstats(nic, xstats, n);
> }
>
Jerin or someone with access to this NIC, could you check
that it works?
[PATCH v5 1/2] dts: add flow rule dataclass to testpmd shell
Add dataclass for passing in flow rule creation arguments, as well as a
__str__ method for converting to a sendable testpmd command.
Signed-off-by: Dean Marx
---
dts/framework/remote_session/testpmd_shell.py | 44 ++-
1 file changed, 43 insertions(+), 1 deletion(-)
diff --git a/dts/framework/remote_session/testpmd_shell.py
b/dts/framework/remote_session/testpmd_shell.py
index d187eaea94..177fcf2e81 100644
--- a/dts/framework/remote_session/testpmd_shell.py
+++ b/dts/framework/remote_session/testpmd_shell.py
@@ -22,7 +22,7 @@
from enum import Flag, auto
from os import environ
from pathlib import PurePath
-from typing import TYPE_CHECKING, Any, ClassVar, Concatenate, ParamSpec,
TypeAlias
+from typing import TYPE_CHECKING, Any, ClassVar, Concatenate, Literal,
ParamSpec, TypeAlias
if TYPE_CHECKING or environ.get("DTS_DOC_BUILD"):
from enum import Enum as NoAliasEnum
@@ -705,6 +705,48 @@ class TestPmdPortStats(TextParser):
tx_bps: int = field(metadata=TextParser.find_int(r"Tx-bps:\s+(\d+)"))
+@dataclass(kw_only=True)
+class FlowRule:
+"""Class representation of flow rule parameters.
+
+This class represents the parameters of any flow rule as per the
+following pattern:
+
+[group {group_id}] [priority {level}] [ingress] [egress]
+[user_id {user_id}] pattern {item} [/ {item} [...]] / end
+actions {action} [/ {action} [...]] / end
+"""
+
+#:
+group_id: int | None = None
+#:
+priority_level: int | None = None
+#:
+direction: Literal["ingress", "egress", "both"]
+#:
+user_id: int | None = None
+#:
+pattern: list[str]
+#:
+actions: list[str]
+
+def __str__(self) -> str:
+"""Returns the string representation of this instance."""
+ret = ""
+pattern = " / ".join(self.pattern)
+action = " / ".join(self.actions)
+if self.group_id is not None:
+ret += f"group {self.group_id} "
+if self.priority_level is not None:
+ret += f"priority {self.priority_level} "
+ret += f"{self.direction} "
+if self.user_id is not None:
+ret += f"user_id {self.user_id} "
+ret += f"pattern {pattern} / end "
+ret += f"actions {action} / end"
+return ret
+
+
class PacketOffloadFlag(Flag):
"""Flag representing the Packet Offload Features Flags in DPDK.
--
2.44.0
[PATCH v5 2/2] dts: add flow create/delete to testpmd shell
Add flow create/delete methods to TestPmdShell class
for initializing flow rules.
Signed-off-by: Dean Marx
---
dts/framework/remote_session/testpmd_shell.py | 59 ++-
1 file changed, 58 insertions(+), 1 deletion(-)
diff --git a/dts/framework/remote_session/testpmd_shell.py
b/dts/framework/remote_session/testpmd_shell.py
index 177fcf2e81..bdb0e760b9 100644
--- a/dts/framework/remote_session/testpmd_shell.py
+++ b/dts/framework/remote_session/testpmd_shell.py
@@ -22,7 +22,15 @@
from enum import Flag, auto
from os import environ
from pathlib import PurePath
-from typing import TYPE_CHECKING, Any, ClassVar, Concatenate, Literal,
ParamSpec, TypeAlias
+from typing import (
+TYPE_CHECKING,
+Any,
+ClassVar,
+Concatenate,
+Literal,
+ParamSpec,
+TypeAlias,
+)
if TYPE_CHECKING or environ.get("DTS_DOC_BUILD"):
from enum import Enum as NoAliasEnum
@@ -1878,6 +1886,55 @@ def csum_set_hw(
{port_id}:\n{csum_output}"""
)
+def flow_create(self, flow_rule: FlowRule, port_id: int, verify: bool =
True) -> int:
+"""Creates a flow rule in the testpmd session.
+
+Args:
+flow_rule: :class:`FlowRule` object used for creating testpmd flow
rule.
+verify: If :data:`True`, the output of the command is scanned
+to ensure the flow rule was created successfully.
+
+Raises:
+InteractiveCommandExecutionError: If flow rule is invalid.
+
+Returns:
+Id of created flow rule as an integer.
+"""
+flow_output = self.send_command(f"flow create {port_id} {flow_rule}")
+if verify:
+if "created" not in flow_output:
+self._logger.debug(f"Failed to create flow
rule:\n{flow_output}")
+raise InteractiveCommandExecutionError(
+f"Failed to create flow rule:\n{flow_output}"
+)
+match = re.search(r"#(\d+)", flow_output)
+if match is not None:
+match_str = match.group(1)
+flow_id = int(match_str)
+return flow_id
+else:
+self._logger.debug(f"Failed to create flow rule:\n{flow_output}")
+raise InteractiveCommandExecutionError(f"Failed to create flow
rule:\n{flow_output}")
+
+def flow_delete(self, flow_id: int, port_id: int, verify: bool = True) ->
None:
+"""Deletes the specified flow rule from the testpmd session.
+
+Args:
+flow_id: :class:`FlowRule` id used for deleting testpmd flow rule.
+verify: If :data:`True`, the output of the command is scanned
+to ensure the flow rule was deleted successfully.
+
+Raises:
+InteractiveCommandExectuionError: If flow rule is invalid.
+"""
+flow_output = self.send_command(f"flow destroy {port_id} rule
{flow_id}")
+if verify:
+if "destroyed" not in flow_output:
+self._logger.debug(f"Failed to delete flow
rule:\n{flow_output}")
+raise InteractiveCommandExecutionError(
+f"Failed to delete flow rule:\n{flow_output}"
+)
+
@requires_stopped_ports
def set_port_mtu(self, port_id: int, mtu: int, verify: bool = True) ->
None:
"""Change the MTU of a port using testpmd.
--
2.44.0
Re: [PATCH] lib/fib: remove warning about implicit 64-bit conversion
On Tue, 3 Dec 2024 18:56:50 -0800
Andre Muezerie wrote:
> MSVC issues the warning below:
>
> ../lib/fib/trie.c(341): warning C4334: '<<':
> result of 32-bit shift implicitly converted to 64 bits
> (was 64-bit shift intended?)
>
> The fix is to cast the result explicitly to ptrdiff_t since it is used
> in pointer arithmetic.
>
> Signed-off-by: Andre Muezerie
> ---
> lib/fib/trie.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/lib/fib/trie.c b/lib/fib/trie.c
> index 4893f6c636..997b7cc338 100644
> --- a/lib/fib/trie.c
> +++ b/lib/fib/trie.c
> @@ -338,7 +338,7 @@ write_edge(struct rte_trie_tbl *dp, const uint8_t
> *ip_part, uint64_t next_hop,
> if (ret < 0)
> return ret;
> if (edge == LEDGE) {
> - write_to_dp((uint8_t *)p + (1 << dp->nh_sz),
> + write_to_dp((uint8_t *)p + (ptrdiff_t)(1 << dp->nh_sz),
> next_hop << 1, dp->nh_sz, UINT8_MAX - *ip_part);
You would be better to use a 64 bit shift or RTE_BIT64 for this.
write_to_dp((uint8_t *)p + ((uintptr_t)1 << dp->nh_sz),
RE: [**EXTERNAL**] Re: rte_mempool_create fails with --no-huge
Hi Dmitry, Your observation is good! But I have the /usr/lib/dpdk/pmds-24.0 in the LD_LIBRARY_PATH but since the host does not have a match glibc, I have to run it with ld-linux-x86-64.so.2 specifying LD_LIBRARY_PATH with equivalent --library-path. Here is the entire cmd I use to run testpmd: sudo /lib/ld-linux-x86-64.so.2 --library-path /lib:/usr/lib:/usr/lib/dpdk:/usr/lib/dpdk/pmds-24.0:/ciena/lib /usr/bin/dpdk-testpmd -c 000F -n 2 --log-level=eal,8 --no-huge -m 4095 --no-pci -- -i --nb-cores=2 --total-num-mbufs=2048 Despite the /lib/dpdk/pmds-24.0 libs being visible, the rte_eal_init does not load any of these shared libs while it does when I run it inside the VM. Would appreciate if you can think of any reasons rte_eal_init does not trigger loading those shared libs in the host run instance. Regards, Mehrdad -Original Message- From: Dmitry Kozlyuk Sent: December 4, 2024 3:51 PM To: Alipour, Mehrdad Cc: dev@dpdk.org Subject: [**EXTERNAL**] Re: rte_mempool_create fails with --no-huge Hi Alipour, It looks suspicious that on the host you don't see logs about loaded drivers, like these ones that you see inside the VM: > 2024-12-03 19:32:36.642042 EAL: open shared lib > /usr/lib/dpdk/pmds-24.0/librte_net_fm10k.so.24.0 > 2024-12-03 19:32:36.642266 EAL: pmd.net.fm10k.init log level changed > from disabled to notice > 2024-12-03 19:32:36.642279 EAL: pmd.net.fm10k.driver log level > changed from disabled to notice > 2024-12-03 19:32:36.642285 EAL: open shared lib > /usr/lib/dpdk/pmds-24.0/librte_net_qdma.so.24.0 > 2024-12-03 19:32:36.642581 EAL: open shared lib > /usr/lib/dpdk/pmds-24.0/librte_net_vhost.so > 2024-12-03 19:32:36.643201 EAL: lib.dmadev log level changed from > disabled to info > 2024-12-03 19:32:36.643264 EAL: Registered [vdpa] device class. Can it be that DPDK on the host does not see shared libraries, e.g. it is not installed in the system and LD_LIBRARY_PATH is not set to shared library location? Then mempool driver would just not be loaded to create a mempool.
Re: [PATCH v2 1/2] usertools/devbind: update coding style
On 12/3/2024 6:07 PM, Stephen Hemminger wrote:
On Tue, 3 Dec 2024 11:25:00 +
Anatoly Burakov wrote:
+
+def check_installed(program: str, package: str) -> None:
+"""Check if a program is installed."""
+if subprocess.call(
+["which", program], stdout=subprocess.DEVNULL,
stderr=subprocess.DEVNULL
+):
+raise DevbindError(f"'{program}' not found - please install
'{package}'.")
+
Apparently the posix way to do this is to use command -v not "which"
command [-pVv] command [arg ...]
Run command with args suppressing the normal shell function
lookup. Only builtin commands or commands found in the PATH are
executed. If the -p option is given, the search for command is
performed using a default value for PATH that is guaranteed to
find all of the standard utilities. If either the -V or -v op‐
tion is supplied, a description of command is printed. The -v
option causes a single word indicating the command or filename
used to invoke command to be displayed; the -V option produces a
more verbose description. If the -V or -v option is supplied,
the exit status is 0 if command was found, and 1 if not. If nei‐
ther option is supplied and an error occurred or command cannot
be found, the exit status is 127. Otherwise, the exit status of
the command builtin is the exit status of command.
Yes but that's for shell, it is not accessible from Python. Well, it
wouldn't be unless you're suggesting calling into bash and running
`command -v`?
--
Thanks,
Anatoly
Re: [PATCH v2 1/2] usertools/devbind: update coding style
On 12/3/2024 11:16 PM, Stephen Hemminger wrote: On Tue, 3 Dec 2024 11:25:00 + Anatoly Burakov wrote: Devbind is one of the oldest tools in DPDK, and is written in a way that uses a lot of string matching, no type safety, lots of global variables, and has a few inconsistencies in the way it handles data (such as differences between lspci calls and parsing in different circumstances). This patch is a nigh complete rewrite of devbind, with full 100% feature and command-line compatibility with the old version (except for dropping older kernel support), albeit with a few differences in formatting and error messages. All file handling code has also been replaced with context managers. What's different from old code: - Full PEP-484 compliance - Formatted with Ruff - Much better structured code - Clean and consistent control flow - More comments - Better error handling - Fewer lspci calls - Unified lspci parsing - Using /sys/bus/pci/drivers as a source of truth about kernel modules - Check for iproute2 package - Use JSON parsing for iproute2 output - Deprecate --status-dev in favor of optional --status argument - Deprecate kernel <3.15 support and only use driver_override Signed-off-by: Anatoly Burakov --- Looks great, like it. Only suggestion (which you can ignore) would be to make DevbindCtx an object with methods bind_devices and print_status, that might simplify. The intention was that DevbindCtx is for processing command-line configuration and for keeping reference to Devbind which does actual work. I feel like the only thing it will simplify is instead of passing ctx around we'll be passing self. I will look into it though, maybe there are some opportunities that I'm missing. Reviewed-by: Stephen HEmminger Thanks! -- Thanks, Anatoly
RE: [PATCH v16 1/4] lib: add generic support for reading PMU events
> From: Stephen Hemminger [mailto:step...@networkplumber.org] > Sent: Wednesday, 4 December 2024 01.55 > > On Wed, 4 Dec 2024 00:49:58 +0100 > Morten Brørup wrote: > > > > From: Stephen Hemminger [mailto:step...@networkplumber.org] > > > Sent: Tuesday, 3 December 2024 22.39 > > > > > > On Mon, 18 Nov 2024 08:37:03 +0100 > > > Tomasz Duszynski wrote: > > > > > > > +Performance counter based profiling > > > > +--- > > > > + > > > > +Majority of architectures support some performance monitoring > unit > > > (PMU). > > > > +Such unit provides programmable counters that monitor specific > > > events. > > > > + > > > > +Different tools gather that information, like for example perf. > > > > +However, in some scenarios when CPU cores are isolated and run > > > > +dedicated tasks interrupting those tasks with perf may be > > > undesirable. > > > > > > The data should be folded into telemetry rather than introducing > yet > > > another > > > DPDK API for applications to deal with. > > > > I strongly prefer the dedicated high-performance PMU API rather than > using telemetry for this. > > Please keep the PMU API. > > > > I expect to call the PMU API in our (proprietary) run-time profiling > library, where reading PMU counters should be as lean as calling > rte_rdtsc(). I sure don't want any superfluous overhead when profiling > with a very high sampling rate. > > > > For reference, many other libraries have dedicated APIs for reading > the statistics structures of those libraries. > > > > A wrapper around the PMU API can be added for Telemetry. > > > > IMO, the Telemetry library should be made optional, like the Trace > library recently was. For embedded systems, they are not only bloat, > but potentially helpful for hackers trying to break in. And Security is > one of the DPDK Governing Board's focus areas. > > > > Can this data go right into perf? > It is not clear why this is better than just using perf? I don't know enough about perf to provide a qualified answer to this. Our data plane profiling library has very high resolution. Think of it gathering information about every single run of each pipeline stage, thus also providing detailed information about outliers. > The one use case I can think of is a cloud provider with lots and lots > of embedded systems. > But in that case they already have much more detailed and integrated > tools, the DPDK stuff is not needed.
[PATCH v3 0/1] Rewrite devbind
It has been suggested [1] that a major cleanup/rewrite of devbind would be beneficial in terms of long term maintainability of the code. I was in a coding mood over the weekend, and so I've went ahead and rewritten devbind. Note that this is one giant patch, rather than a series of patches adjusting existing code. Making it a patch series is possible, however the internal code architecture diverges quite significantly from the original devbind script due to its copious usage of string operations/pattern matching and global variables, so it is unclear whether subdividing this patch would be worth the effort. Instead, as has been suggested [2], the patchset now consists of creating a new file, followed by a removal of old file and rename of the new file. It is expected that this will be squashed on apply. The script has become slightly bigger - 1000 lines instead of 800, however I would argue that since most of that increase is infrastructure, comments, and sacrificing code golf for code readability (such as expanding one-liners into multiple lines), the trade-off between being able to read and reason about what happens in the script is worth the added line count. [1] https://patches.dpdk.org/project/dpdk/patch/c2bf00195c2d43833a831a9cc9346b4606d6ea2e.1723810613.git.anatoly.bura...@intel.com/ [2] https://patches.dpdk.org/project/dpdk/cover/cover.1733151400.git.anatoly.bura...@intel.com/ Anatoly Burakov (1): usertools/devbind: replace devbind usertools/dpdk-devbind-new.py | 995 --- usertools/dpdk-devbind.py | 1683 ++--- 2 files changed, 913 insertions(+), 1765 deletions(-) delete mode 100755 usertools/dpdk-devbind-new.py -- 2.43.5
[PATCH v3 0/2] Rewrite devbind
It has been suggested [1] that a major cleanup/rewrite of devbind would be beneficial in terms of long term maintainability of the code. I was in a coding mood over the weekend, and so I've went ahead and rewritten devbind. Note that this is one giant patch, rather than a series of patches adjusting existing code. Making it a patch series is possible, however the internal code architecture diverges quite significantly from the original devbind script due to its copious usage of string operations/pattern matching and global variables, so it is unclear whether subdividing this patch would be worth the effort. Instead, as has been suggested [2], the patchset now consists of creating a new file, followed by a removal of old file and rename of the new file. It is expected that this will be squashed on apply. The script has become slightly bigger - 1000 lines instead of 800, however I would argue that since most of that increase is infrastructure, comments, and sacrificing code golf for code readability (such as expanding one-liners into multiple lines), the trade-off between being able to read and reason about what happens in the script is worth the added line count. [1] https://patches.dpdk.org/project/dpdk/patch/c2bf00195c2d43833a831a9cc9346b4606d6ea2e.1723810613.git.anatoly.bura...@intel.com/ [2] https://patches.dpdk.org/project/dpdk/cover/cover.1733151400.git.anatoly.bura...@intel.com/ Anatoly Burakov (2): usertools/devbind: update coding style usertools/devbind: replace devbind doc/guides/tools/devbind.rst | 11 + usertools/dpdk-devbind.py| 1683 ++ 2 files changed, 924 insertions(+), 770 deletions(-) -- 2.43.5
Re: [PATCH v3 0/1] Rewrite devbind
On 12/4/2024 10:45 AM, Anatoly Burakov wrote: It has been suggested [1] that a major cleanup/rewrite of devbind would be beneficial in terms of long term maintainability of the code. I was in a coding mood over the weekend, and so I've went ahead and rewritten devbind. Note that this is one giant patch, rather than a series of patches adjusting existing code. Making it a patch series is possible, however the internal code architecture diverges quite significantly from the original devbind script due to its copious usage of string operations/pattern matching and global variables, so it is unclear whether subdividing this patch would be worth the effort. Instead, as has been suggested [2], the patchset now consists of creating a new file, followed by a removal of old file and rename of the new file. It is expected that this will be squashed on apply. The script has become slightly bigger - 1000 lines instead of 800, however I would argue that since most of that increase is infrastructure, comments, and sacrificing code golf for code readability (such as expanding one-liners into multiple lines), the trade-off between being able to read and reason about what happens in the script is worth the added line count. [1] https://patches.dpdk.org/project/dpdk/patch/c2bf00195c2d43833a831a9cc9346b4606d6ea2e.1723810613.git.anatoly.bura...@intel.com/ [2] https://patches.dpdk.org/project/dpdk/cover/cover.1733151400.git.anatoly.bura...@intel.com/ Anatoly Burakov (1): usertools/devbind: replace devbind usertools/dpdk-devbind-new.py | 995 --- usertools/dpdk-devbind.py | 1683 ++--- 2 files changed, 913 insertions(+), 1765 deletions(-) delete mode 100755 usertools/dpdk-devbind-new.py Please disregard this, scripting mishap. -- Thanks, Anatoly
[PATCH] lib/gso: rte_gso_segment function increases the processing of ipv6 tcp packets
From: liaocaiqiang
---
lib/gso/gso_common.h | 39 +++
lib/gso/gso_tcp6.c| 62 +
lib/gso/gso_tcp6.h| 43
lib/gso/gso_tunnel_tcp6.c | 82 +++
lib/gso/gso_tunnel_tcp6.h | 44 +
lib/gso/meson.build | 2 +
lib/gso/rte_gso.c | 18 +
7 files changed, 290 insertions(+)
create mode 100644 lib/gso/gso_tcp6.c
create mode 100644 lib/gso/gso_tcp6.h
create mode 100644 lib/gso/gso_tunnel_tcp6.c
create mode 100644 lib/gso/gso_tunnel_tcp6.h
diff --git a/lib/gso/gso_common.h b/lib/gso/gso_common.h
index d1c1b73091..aaea2ae9c6 100644
--- a/lib/gso/gso_common.h
+++ b/lib/gso/gso_common.h
@@ -38,6 +38,20 @@
#define IS_IPV4_UDP(flag) (((flag) & (RTE_MBUF_F_TX_UDP_SEG |
RTE_MBUF_F_TX_IPV4)) == \
(RTE_MBUF_F_TX_UDP_SEG | RTE_MBUF_F_TX_IPV4))
+#define IS_IPV6_TCP(flag) (((flag) & (RTE_MBUF_F_TX_TCP_SEG |
RTE_MBUF_F_TX_IPV6)) == \
+ (RTE_MBUF_F_TX_TCP_SEG | RTE_MBUF_F_TX_IPV6))
+
+#define IS_IPV4_VXLAN_TCP6(flag) (((flag) & (RTE_MBUF_F_TX_TCP_SEG |
RTE_MBUF_F_TX_IPV6 | \
+ RTE_MBUF_F_TX_OUTER_IPV4 |
RTE_MBUF_F_TX_TUNNEL_MASK)) == \
+ (RTE_MBUF_F_TX_TCP_SEG | RTE_MBUF_F_TX_IPV6 |
RTE_MBUF_F_TX_OUTER_IPV4 | \
+RTE_MBUF_F_TX_TUNNEL_VXLAN))
+
+#define IS_IPV4_GRE_TCP6(flag) (((flag) & (RTE_MBUF_F_TX_TCP_SEG |
RTE_MBUF_F_TX_IPV6 | \
+ RTE_MBUF_F_TX_OUTER_IPV4 |
RTE_MBUF_F_TX_TUNNEL_MASK)) == \
+ (RTE_MBUF_F_TX_TCP_SEG | RTE_MBUF_F_TX_IPV6 |
RTE_MBUF_F_TX_OUTER_IPV4 | \
+RTE_MBUF_F_TX_TUNNEL_GRE))
+
+
/**
* Internal function which updates the UDP header of a packet, following
* segmentation. This is required to update the header's datagram length field.
@@ -110,6 +124,31 @@ update_ipv4_header(struct rte_mbuf *pkt, uint16_t
l3_offset, uint16_t id)
ipv4_hdr->packet_id = rte_cpu_to_be_16(id);
}
+/**
+ * Internal function which updates the IPv6 header of a packet, following
+ * segmentation. This is required to update the header's 'total_length' field,
+ * to reflect the reduced length of the now-segmented packet. Furthermore, the
+ * header's 'packet_id' field must be updated to reflect the new ID of the
+ * now-segmented packet.
+ *
+ * @param pkt
+ * The packet containing the IPv6 header.
+ * @param l3_offset
+ * The offset of the IPv6 header from the start of the packet.
+ * @param id
+ * The new ID of the packet.
+ */
+static inline void
+update_ipv6_header(struct rte_mbuf *pkt, uint16_t l3_offset)
+{
+struct rte_ipv6_hdr *ipv6_hdr;
+
+ipv6_hdr = (struct rte_ipv6_hdr *)(rte_pktmbuf_mtod(pkt, char *) +
+ l3_offset);
+ipv6_hdr->payload_len = htons(pkt->pkt_len - l3_offset - sizeof(struct
rte_ipv6_hdr));
+}
+
+
/**
* Internal function which divides the input packet into small segments.
* Each of the newly-created segments is organized as a two-segment MBUF,
diff --git a/lib/gso/gso_tcp6.c b/lib/gso/gso_tcp6.c
new file mode 100644
index 00..344550a5a8
--- /dev/null
+++ b/lib/gso/gso_tcp6.c
@@ -0,0 +1,62 @@
+/* SPDX-License-Identifier: BSD-3-Clause
+ * Copyright(c) 2017 Intel Corporation
+ */
+
+#include "gso_common.h"
+#include "gso_tcp6.h"
+
+static void
+update_ipv6_tcp_headers(struct rte_mbuf *pkt, struct rte_mbuf **segs,
+uint16_t nb_segs)
+{
+struct rte_ipv6_hdr *ipv6_hdr;
+struct rte_tcp_hdr *tcp_hdr;
+uint32_t sent_seq;
+uint16_t tail_idx, i;
+uint16_t l3_offset = pkt->l2_len;
+uint16_t l4_offset = l3_offset + pkt->l3_len;
+
+ipv6_hdr = (struct rte_ipv6_hdr *)(rte_pktmbuf_mtod(pkt, char*) +
+ l3_offset);
+tcp_hdr = (struct rte_tcp_hdr *)((char *)ipv6_hdr + pkt->l3_len);
+sent_seq = ntohl(tcp_hdr->sent_seq);
+tail_idx = nb_segs - 1;
+
+for (i = 0; i < nb_segs; i++) {
+update_ipv6_header(segs[i], l3_offset);
+update_tcp_header(segs[i], l4_offset, sent_seq, i < tail_idx);
+sent_seq += (segs[i]->pkt_len - segs[i]->data_len);
+}
+}
+
+int
+gso_tcp6_segment(struct rte_mbuf *pkt, uint16_t gso_size,
+ struct rte_mempool *direct_pool,
+ struct rte_mempool *indirect_pool,
+ struct rte_mbuf **pkts_out,
+ uint16_t nb_pkts_out)
+{
+ uint16_t pyld_unit_size, hdr_offset;
+ int ret = 1;
+
+ hdr_offset = pkt->l2_len;
+ hdr_offset += pkt->l3_len + pkt->l4_len;
+
+ /* Don't process the packet without data */
+ if (hdr_offset >= pkt->pkt_len) {
+ return 0;
+ }
+ pyld_unit_size = gso_size - hdr_offset;
+
+ /* Segment the payload */
+ ret = gso_do_segment(pkt, hdr_offset, pyld_unit_size, direct_pool,
+ indirect_pool, pkts
[PATCH] version: 24.11.0
From: Thomas Monjalon Signed-off-by: Thomas Monjalon --- VERSION | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/VERSION b/VERSION index c09465eb07..0a492611a0 100644 --- a/VERSION +++ b/VERSION @@ -1 +1 @@ -24.11.0-rc4 +24.11.0 -- 2.43.0.windows.1
[PATCH v3 1/1] usertools/devbind: replace devbind
Signed-off-by: Anatoly Burakov
---
Notes:
v2:
- Added this patch to aid in review
- I believe it's better to squash it on apply
usertools/dpdk-devbind-new.py | 995 ---
usertools/dpdk-devbind.py | 1683 ++---
2 files changed, 913 insertions(+), 1765 deletions(-)
delete mode 100755 usertools/dpdk-devbind-new.py
diff --git a/usertools/dpdk-devbind-new.py b/usertools/dpdk-devbind-new.py
deleted file mode 100755
index 1f2d8cb118..00
--- a/usertools/dpdk-devbind-new.py
+++ /dev/null
@@ -1,995 +0,0 @@
-#!/usr/bin/env python3
-# SPDX-License-Identifier: BSD-3-Clause
-# Copyright(c) 2010-2024 Intel Corporation
-#
-"""Script to bind PCI devices to DPDK-compatible userspace IO drivers."""
-
-import argparse
-import glob
-import grp
-import json
-import os
-import pwd
-import subprocess
-import sys
-import typing as T
-
-# the following list of modules is supported by DPDK
-DPDK_KERNEL_MODULES = {"igb_uio", "vfio-pci", "uio_pci_generic"}
-
-# pattern matching criteria for various devices and devices classes. keys are
entries in lspci,
-# while values, if present are further matches for lspci criteria. values can
be either strings or
-# list of strings, in which case any match is sufficient.
-StrOrList = T.Union[str, T.List[str]]
-DeviceMatchPattern = T.Dict[str, StrOrList]
-CLASS_NETWORK: DeviceMatchPattern = {
-"Class": "02",
-}
-CLASS_ACCELERATION: DeviceMatchPattern = {
-"Class": "12",
-}
-CLASS_IFPGA: DeviceMatchPattern = {
-"Class": "12",
-"Vendor": "8086",
-"Device": "0b30",
-}
-CLASS_ENCRYPTION: DeviceMatchPattern = {
-"Class": "10",
-}
-CLASS_INTEL_PROCESSOR: DeviceMatchPattern = {
-"Class": "0b",
-"Vendor": "8086",
-}
-DEVICE_CAVIUM_SSO: DeviceMatchPattern = {
-"Class": "08",
-"Vendor": "177d",
-"Device": ["a04b", "a04d"],
-}
-DEVICE_CAVIUM_FPA: DeviceMatchPattern = {
-"Class": "08",
-"Vendor": "177d",
-"Device": "a053",
-}
-DEVICE_CAVIUM_PKX: DeviceMatchPattern = {
-"Class": "08",
-"Vendor": "177d",
-"Device": ["a0dd", "a049"],
-}
-DEVICE_CAVIUM_TIM: DeviceMatchPattern = {
-"Class": "08",
-"Vendor": "177d",
-"Device": "a051",
-}
-DEVICE_CAVIUM_ZIP: DeviceMatchPattern = {
-"Class": "12",
-"Vendor": "177d",
-"Device": "a037",
-}
-DEVICE_AVP_VNIC: DeviceMatchPattern = {
-"Class": "05",
-"Vendor": "1af4",
-"Device": "1110",
-}
-DEVICE_CNXK_BPHY: DeviceMatchPattern = {
-"Class": "08",
-"Vendor": "177d",
-"Device": "a089",
-}
-DEVICE_CNXK_BPHY_CGX: DeviceMatchPattern = {
-"Class": "08",
-"Vendor": "177d",
-"Device": ["a059", "a060"],
-}
-DEVICE_CNXK_DMA: DeviceMatchPattern = {
-"Class": "08",
-"Vendor": "177d",
-"Device": "a081",
-}
-DEVICE_CNXK_INL_DEV: DeviceMatchPattern = {
-"Class": "08",
-"Vendor": "177d",
-"Device": ["a0f0", "a0f1"],
-}
-DEVICE_HISILICON_DMA: DeviceMatchPattern = {
-"Class": "08",
-"Vendor": "19e5",
-"Device": "a122",
-}
-DEVICE_ODM_DMA: DeviceMatchPattern = {
-"Class": "08",
-"Vendor": "177d",
-"Device": "a08c",
-}
-DEVICE_INTEL_DLB: DeviceMatchPattern = {
-"Class": "0b",
-"Vendor": "8086",
-"Device": ["270b", "2710", "2714"],
-}
-DEVICE_INTEL_IOAT_BDW: DeviceMatchPattern = {
-"Class": "08",
-"Vendor": "8086",
-"Device": [
-"6f20",
-"6f21",
-"6f22",
-"6f23",
-"6f24",
-"6f25",
-"6f26",
-"6f27",
-"6f2e",
-"6f2f",
-],
-}
-DEVICE_INTEL_IOAT_SKX: DeviceMatchPattern = {
-"Class": "08",
-"Vendor": "8086",
-"Device": "2021",
-}
-DEVICE_INTEL_IOAT_ICX: DeviceMatchPattern = {
-"Class": "08",
-"Vendor": "8086",
-"Device": "0b00",
-}
-DEVICE_INTEL_IDXD_SPR: DeviceMatchPattern = {
-"Class": "08",
-"Vendor": "8086",
-"Device": "0b25",
-}
-DEVICE_INTEL_NTB_SKX: DeviceMatchPattern = {
-"Class": "06",
-"Vendor": "8086",
-"Device": "201c",
-}
-DEVICE_INTEL_NTB_ICX: DeviceMatchPattern = {
-"Class": "06",
-"Vendor": "8086",
-"Device": "347e",
-}
-DEVICE_CNXK_SSO: DeviceMatchPattern = {
-"Class": "08",
-"Vendor": "177d",
-"Device": ["a0f9", "a0fa"],
-}
-DEVICE_CNXK_NPA: DeviceMatchPattern = {
-"Class": "08",
-"Vendor": "177d",
-"Device": ["a0fb", "a0fc"],
-}
-DEVICE_CN9K_REE: DeviceMatchPattern = {
-"Class": "08",
-"Vendor": "177d",
-"Device": "a0f4",
-}
-DEVICE_VIRTIO_BLK: DeviceMatchPattern = {
-"Class": "01",
-"Vendor": "1af4",
-"Device": ["1001", "1042"],
-}
-DEVICE_CNXK_ML: DeviceMatchPattern = {
-"Class": "08",
-"Vendor": "177d",
-"Device": "a092",
-}
-
-# device types as recognized by devbind
-NETWORK_DEVICES = [CLASS_NETWORK, CLASS_IFPGA, DEVICE_CAVIUM_PKX,
DEVICE_AVP_VNIC]
-BASEDBAND_DEVICES = [CLASS_ACCELERATION]
-CRYPTO_DEVICES = [CLASS_ENCRYPTION, CLASS_INTEL_PROCESSOR]
-DMA_DEVICES = [
-DEVICE_CNXK_DMA,
-DEVICE_HISIL
Re:Re: [PATCH] vhost: Fix the crash caused by accessing the released memory
Hello Maxime Coquelin，
The scenario where I encountered coredump was ovs-dpdk，
similar to patch:
https://github.com/DPDK/dpdk/commit/52d874dc67055a943867456d3e5c730168bfba18.
Only one thread called rte_vhost_driver_unregister(), but at the same time,
two other threads called vhost_user_read_cb() and vhost_user_client_reconnect()
respectively.
The specific reasons for coredump are as follows：
vhostuser port is created as client.
Thread 1 calls rte_vhost_driver_unregister() to remove the vsocket of reconn
from the reconn list.
then “vhost-events” thread calls vhost_user_read_cb() to add the vsocket of
reconn back to the reconn list.
At this time, after thread 1 releases the vsocket memory, the socket of
vhostuser reconnects successfully,
"vhost_reconn" thread will access the released memory.
Therefore, The fix is to perform a delete operation again after releasing the
memory.
I have resubmitted the patch, please review it again.
https://patches.dpdk.org/project/dpdk/patch/20240625093149.63247-1-15957197...@163.com/
At 2024-06-24 17:20:00, "Maxime Coquelin" wrote:
>Hi,
>
>On 6/19/24 14:27, zhaoxinxin wrote:
>> The rte_vhost_driver_unregister() vhost_user_read_cb()
>> vhost_user_client_reconnect() can be called at the same time by 3 threads.
>> when memory of vsocket is freed in rte_vhost_driver_unregister(),
>> then vhost_user_read_cb() maybe add vsocket to reconn_list,
>> the invalid memory of vsocket is accessed in vhost_user_client_reconnect().
>
>It is not clear to me why 3 threads are calling
>rte_vhost_driver_unregister() at the same time, isn't it an application
>issue?
>
>> The core trace is:
>> Program terminated with signal 11, Segmentation fault.
>> The fix is to perform a delete operation again after releasing the memory
>>
>
>We need a Fixes tag and Cc sta...@dpdk.org so that it is backported.
>
>> Signed-off-by: zhaoxinxin <15957197...@163.com>
>
>The format is Firstname Lastname
>
>
>> ---
>> lib/vhost/socket.c | 2 ++
>> 1 file changed, 2 insertions(+)
>>
>> diff --git a/lib/vhost/socket.c b/lib/vhost/socket.c
>> index a75728a2e4..01946096c4 100644
>> --- a/lib/vhost/socket.c
>> +++ b/lib/vhost/socket.c
>> @@ -1121,6 +1121,8 @@ rte_vhost_driver_unregister(const char *path)
>> if (vsocket->is_server) {
>> close(vsocket->socket_fd);
>> unlink(path);
>> +} else if (vsocket->reconnect) {
>> +vhost_user_remove_reconnect(vsocket);
>> }
>>
>> pthread_mutex_destroy(&vsocket->conn_mutex);
Re: [PATCH] version: 25.03-rc0
03/12/2024 08:54, David Marchand: > Start a new release cycle with empty release notes. > Bump version and ABI minor. > Bump libabigail from 2.4 to 2.6 and enable ABI checks. > > Signed-off-by: David Marchand Acked-by: Thomas Monjalon Added a note about the new libabigail which will allow us to split a library (like EAL) without having warnings. Applied, so a new release cycle is started! Note to all branch maintainers: please rebase on this commit and enable ABI checks in your local configuration. Happy 25.03 :)
[PATCH v3 2/2] usertools/devbind: replace devbind
Signed-off-by: Anatoly Burakov
---
Notes:
v2:
- Added this patch to aid in review
- I believe it's better to squash it on apply
usertools/dpdk-devbind-new.py | 995 ---
usertools/dpdk-devbind.py | 1683 ++---
2 files changed, 913 insertions(+), 1765 deletions(-)
delete mode 100755 usertools/dpdk-devbind-new.py
diff --git a/usertools/dpdk-devbind-new.py b/usertools/dpdk-devbind-new.py
deleted file mode 100755
index 1f2d8cb118..00
--- a/usertools/dpdk-devbind-new.py
+++ /dev/null
@@ -1,995 +0,0 @@
-#!/usr/bin/env python3
-# SPDX-License-Identifier: BSD-3-Clause
-# Copyright(c) 2010-2024 Intel Corporation
-#
-"""Script to bind PCI devices to DPDK-compatible userspace IO drivers."""
-
-import argparse
-import glob
-import grp
-import json
-import os
-import pwd
-import subprocess
-import sys
-import typing as T
-
-# the following list of modules is supported by DPDK
-DPDK_KERNEL_MODULES = {"igb_uio", "vfio-pci", "uio_pci_generic"}
-
-# pattern matching criteria for various devices and devices classes. keys are
entries in lspci,
-# while values, if present are further matches for lspci criteria. values can
be either strings or
-# list of strings, in which case any match is sufficient.
-StrOrList = T.Union[str, T.List[str]]
-DeviceMatchPattern = T.Dict[str, StrOrList]
-CLASS_NETWORK: DeviceMatchPattern = {
-"Class": "02",
-}
-CLASS_ACCELERATION: DeviceMatchPattern = {
-"Class": "12",
-}
-CLASS_IFPGA: DeviceMatchPattern = {
-"Class": "12",
-"Vendor": "8086",
-"Device": "0b30",
-}
-CLASS_ENCRYPTION: DeviceMatchPattern = {
-"Class": "10",
-}
-CLASS_INTEL_PROCESSOR: DeviceMatchPattern = {
-"Class": "0b",
-"Vendor": "8086",
-}
-DEVICE_CAVIUM_SSO: DeviceMatchPattern = {
-"Class": "08",
-"Vendor": "177d",
-"Device": ["a04b", "a04d"],
-}
-DEVICE_CAVIUM_FPA: DeviceMatchPattern = {
-"Class": "08",
-"Vendor": "177d",
-"Device": "a053",
-}
-DEVICE_CAVIUM_PKX: DeviceMatchPattern = {
-"Class": "08",
-"Vendor": "177d",
-"Device": ["a0dd", "a049"],
-}
-DEVICE_CAVIUM_TIM: DeviceMatchPattern = {
-"Class": "08",
-"Vendor": "177d",
-"Device": "a051",
-}
-DEVICE_CAVIUM_ZIP: DeviceMatchPattern = {
-"Class": "12",
-"Vendor": "177d",
-"Device": "a037",
-}
-DEVICE_AVP_VNIC: DeviceMatchPattern = {
-"Class": "05",
-"Vendor": "1af4",
-"Device": "1110",
-}
-DEVICE_CNXK_BPHY: DeviceMatchPattern = {
-"Class": "08",
-"Vendor": "177d",
-"Device": "a089",
-}
-DEVICE_CNXK_BPHY_CGX: DeviceMatchPattern = {
-"Class": "08",
-"Vendor": "177d",
-"Device": ["a059", "a060"],
-}
-DEVICE_CNXK_DMA: DeviceMatchPattern = {
-"Class": "08",
-"Vendor": "177d",
-"Device": "a081",
-}
-DEVICE_CNXK_INL_DEV: DeviceMatchPattern = {
-"Class": "08",
-"Vendor": "177d",
-"Device": ["a0f0", "a0f1"],
-}
-DEVICE_HISILICON_DMA: DeviceMatchPattern = {
-"Class": "08",
-"Vendor": "19e5",
-"Device": "a122",
-}
-DEVICE_ODM_DMA: DeviceMatchPattern = {
-"Class": "08",
-"Vendor": "177d",
-"Device": "a08c",
-}
-DEVICE_INTEL_DLB: DeviceMatchPattern = {
-"Class": "0b",
-"Vendor": "8086",
-"Device": ["270b", "2710", "2714"],
-}
-DEVICE_INTEL_IOAT_BDW: DeviceMatchPattern = {
-"Class": "08",
-"Vendor": "8086",
-"Device": [
-"6f20",
-"6f21",
-"6f22",
-"6f23",
-"6f24",
-"6f25",
-"6f26",
-"6f27",
-"6f2e",
-"6f2f",
-],
-}
-DEVICE_INTEL_IOAT_SKX: DeviceMatchPattern = {
-"Class": "08",
-"Vendor": "8086",
-"Device": "2021",
-}
-DEVICE_INTEL_IOAT_ICX: DeviceMatchPattern = {
-"Class": "08",
-"Vendor": "8086",
-"Device": "0b00",
-}
-DEVICE_INTEL_IDXD_SPR: DeviceMatchPattern = {
-"Class": "08",
-"Vendor": "8086",
-"Device": "0b25",
-}
-DEVICE_INTEL_NTB_SKX: DeviceMatchPattern = {
-"Class": "06",
-"Vendor": "8086",
-"Device": "201c",
-}
-DEVICE_INTEL_NTB_ICX: DeviceMatchPattern = {
-"Class": "06",
-"Vendor": "8086",
-"Device": "347e",
-}
-DEVICE_CNXK_SSO: DeviceMatchPattern = {
-"Class": "08",
-"Vendor": "177d",
-"Device": ["a0f9", "a0fa"],
-}
-DEVICE_CNXK_NPA: DeviceMatchPattern = {
-"Class": "08",
-"Vendor": "177d",
-"Device": ["a0fb", "a0fc"],
-}
-DEVICE_CN9K_REE: DeviceMatchPattern = {
-"Class": "08",
-"Vendor": "177d",
-"Device": "a0f4",
-}
-DEVICE_VIRTIO_BLK: DeviceMatchPattern = {
-"Class": "01",
-"Vendor": "1af4",
-"Device": ["1001", "1042"],
-}
-DEVICE_CNXK_ML: DeviceMatchPattern = {
-"Class": "08",
-"Vendor": "177d",
-"Device": "a092",
-}
-
-# device types as recognized by devbind
-NETWORK_DEVICES = [CLASS_NETWORK, CLASS_IFPGA, DEVICE_CAVIUM_PKX,
DEVICE_AVP_VNIC]
-BASEDBAND_DEVICES = [CLASS_ACCELERATION]
-CRYPTO_DEVICES = [CLASS_ENCRYPTION, CLASS_INTEL_PROCESSOR]
-DMA_DEVICES = [
-DEVICE_CNXK_DMA,
-DEVICE_HISIL
Re: [PATCH] version: 25.03-rc0
On Wed, Dec 4, 2024 at 11:06 AM Thomas Monjalon wrote: > > 03/12/2024 08:54, David Marchand: > > Start a new release cycle with empty release notes. > > Bump version and ABI minor. > > Bump libabigail from 2.4 to 2.6 and enable ABI checks. > > > > Signed-off-by: David Marchand > Acked-by: Thomas Monjalon > > Added a note about the new libabigail which will allow us > to split a library (like EAL) without having warnings. > > Applied, so a new release cycle is started! > > Note to all branch maintainers: please rebase on this commit > and enable ABI checks in your local configuration. > > Happy 25.03 :) Time to re-enable ABI checks in CI too (please note that libabigail version has been bumped). -- David Marchand
Re: [PATCH v4 1/1] usertools/devbind: allow changing UID/GID for VFIO
On 12/2/2024 10:31 AM, Anatoly Burakov wrote: Currently, when binding a device to VFIO, the UID/GID for the device will always stay as system default (`root`). Yet, when running DPDK as non-root user, one has to change the UID/GID of the device to match the user's UID/GID to use the device. This patch adds an option to `dpdk-devbind.py` to change the UID/GID of the device when binding it to VFIO. Signed-off-by: Anatoly Burakov --- This functionality is also included in my devbind rewrite: https://patches.dpdk.org/project/dpdk/list/?series=34098 -- Thanks, Anatoly
RE: lib/eal/arm/include/rte_vect.h fails to compile with clang14 for 32bit ARM
> > clang14 does appear to support the vcopyq_laneq_u32() intrinsic, s0 we want > to skip the conditional implementation. > > Two approaches I have tested to resolve the error are: > > 1) skip if building with clang: > > > #if !defined(__clang__) && ((defined(RTE_ARCH_ARM) && > defined(RTE_ARCH_32)) || \ > 72 (defined(RTE_ARCH_ARM64) && RTE_CC_IS_GNU && > (GCC_VERSION < 7))) Use RTE_CC_CLANG instead of __clang__ > > 2) skip if not building for ARMv7: > > > > > #if (defined(RTE_ARCH_ARMv7) && defined(RTE_ARCH_32)) || \ > (defined(RTE_ARCH_ARM64) && RTE_CC_IS_GNU && (GCC_VERSION > < 7)) > > > > Both address our immediate problem, but may not be a appropriate for all > cases. > > Can anyone suggest the proper way to address this? I'll be submitting an > patch once I have a solution that is acceptable to the community. I prefer skipping for clang (option 1) --wathsala
21.11.9 patches review and test
Hi all, Here is a list of patches targeted for stable release 21.11.9. The planned date for the final release is 17th December 2024. Please help with testing and validation of your use cases and report any issues/results with reply-all to this mail. For the final release the fixes and reported validations will be added to the release notes. A release candidate tarball can be found at: https://dpdk.org/browse/dpdk-stable/tag/?id=v21.11.9-rc1 These patches are located at branch 21.11 of dpdk-stable repo: https://dpdk.org/browse/dpdk-stable/ Thanks. Kevin --- Ajit Khaparde (1): net/bnxt: fix TCP and UDP checksum flags Alan Elder (1): net/netvsc: fix using Tx queue higher than Rx queues Aleksandr Loktionov (1): net/i40e/base: fix misleading debug logs and comments Alexander Kozyrev (3): net/mlx5: fix shared queue port number in vector Rx common/mlx5: fix error CQE handling for 128 bytes CQE net/mlx5: fix miniCQEs number calculation Anatoly Burakov (1): net/i40e/base: fix setting flags in init function Andre Muezerie (1): rcu: fix implicit conversion in bit shift Artur Tyminski (1): net/i40e/base: fix DDP loading with reserved track ID Barbara Skobiej (3): net/ixgbe/base: fix unchecked return value net/i40e/base: fix unchecked return value net/i40e/base: fix loop bounds Bill Xiang (2): vhost: fix offset while mapping log base address vdpa: update used flags in used ring relay Bing Zhao (1): net/mlx5: workaround list management of Rx queue control Bruce Richardson (10): eal/x86: fix 32-bit write combining store net/i40e: fix AVX-512 pointer copy on 32-bit net/ice: fix AVX-512 pointer copy on 32-bit net/iavf: fix AVX-512 pointer copy on 32-bit build: remove version check on compiler links function net/ice: detect stopping a flow director queue twice app/dumpcap: remove unused struct array eventdev: fix possible array underflow/overflow net/iavf: add segment-length check to Tx prep net/iavf: fix VF reset when using DCF Chaoyong He (1): net/nfp: fix link change return value Chengwen Feng (6): examples/eventdev: fix queue crash with generic pipeline ethdev: verify queue ID in Tx done cleanup net/hns3: verify reset type from firmware dmadev: fix potential null pointer access net/hns3: restrict tunnel flow rule to one header net/mvneta: fix possible out-of-bounds write Danylo Vodopianov (1): app/testpmd: fix aged flow destroy Dave Ertman (1): net/ice/base: fix VLAN replay after reset David Marchand (2): net/iavf: preserve MAC address with i40e PF Linux driver crypto/openssl: fix 3DES-CTR with big endian CPUs Dengdui Huang (2): net/hns3: fix error code for repeatedly create counter net/hns3: fix fully use hardware flow director table Eryk Rybak (1): net/i40e/base: fix blinking X722 with X557 PHY Fabio Pricoco (2): net/ice/base: add bounds check net/ice/base: fix iteration of TLVs in Preserved Fields Area Farah Smith (1): net/bnxt/tf_core: fix Thor TF EM key size check Fidaullah Noonari (1): app/procinfo: fix leak on exit Gagandeep Singh (2): crypto/dpaa2_sec: fix memory leak bus/dpaa: fix PFDRs leaks due to FQRNIs Hanumanth Pothula (1): event/octeontx: fix possible integer overflow Hemant Agrawal (4): bus/dpaa: fix VSP for 1G fm1-mac9 and 10 bus/dpaa: fix the fman details status examples/l2fwd-event: fix spinlock handling bus/dpaa: fix lock condition during error handling Igor Gutorov (1): net/mlx5: fix reported Rx/Tx descriptor limits Jiawen Wu (8): net/txgbe: fix SWFW mbox net/txgbe: fix VF-PF mbox interrupt net/txgbe: remove outer UDP checksum capability net/txgbe: fix driver load bit to inform firmware net/ngbe: fix driver load bit to inform firmware net/ngbe: reconfigure more MAC Rx registers net/ngbe: fix interrupt lost in legacy or MSI mode net/ngbe: restrict configuration of VLAN strip offload Jie Hai (2): net/hns3: remove some basic address dump net/hns3: fix dump counter of registers Jun Wang (1): net/e1000: fix link status crash in secondary process Kaiwen Deng (1): net/iavf: fix crash when link is unstable Kiran Kumar K (1): common/cnxk: fix RSS key configuration Kommula Shiva Shankar (1): net/virtio-user: reset used index counter Lewis Donzis (1): net/ixgbe: fix link status delay on FreeBSD Long Li (1): net/netvsc: force Tx VLAN offload on 801.2Q packet Malcolm Bumgardner (1): dev: fix callback lookup when unregistering device Mihai Brodschi (1): net/memif: fix buffer overflow in zero copy Rx Niall Meade (1): ethdev: fix overflow in descriptor count Paul Greenwalt (1): net/ice/base: fix link speed for 200G Peter Morrow (1): net/b
Re: [PATCH v1 1/1] usertools/devbind: add documentation for no-IOMMU mode
On 12/2/2024 10:35 AM, Anatoly Burakov wrote: Support for `--noiommu-mode` flag was added, but documentation for it was not. Add documentation for the flag. Signed-off-by: Anatoly Burakov --- This update is also included in my devbind rewrite: https://patches.dpdk.org/project/dpdk/list/?series=34098 -- Thanks, Anatoly
Re: [PATCH] lib/lpm: use standard atomic_store_explicit
On Wed, Dec 04, 2024 at 08:56:35AM +0100, David Marchand wrote: > Hello Andre, > > On Wed, Dec 4, 2024 at 3:20 AM Andre Muezerie > wrote: > > > > MSVC issues the warning below: > > > > ../lib/lpm/rte_lpm.c(297): warning C4013 > > '__atomic_store' undefined; assuming extern returning int > > ../lib/lpm/rte_lpm.c(298): error C2065: > > '__ATOMIC_RELAXED': undeclared identifier > > > > The fix is to use standard atomic_store_explicit() instead of > > gcc specific __atomic_store(). > > atomic_store_explicit() was already being used in other parts > > of DPDK and is compatible > > with many compilers, including MSVC. > > > > Signed-off-by: Andre Muezerie > > With this change, is there anything remaining that blocks this library > compilation with MSVC? > If not, please update meson.build so that CI can test lpm compilation > with MSVC on this patch (and that will detect regressions once > merged). > > > -- > David Marchand Hi David, I'm eager to enable lpm to be compiled with MSVC. Even though this was the last issue I observed for this lib on my machine, lpm depends on hash, which depends on net, which depends on mbuf and mbuf is not enabled for MSVC yet. I have several fixes affecting these pending review and would prefer to not depend on lpm's dependencies for the system to start compiling this code in case some critical fix gets completed later. I have not analyzed all sequences in which patches can be completed, and it's quite possible that some sequences would result in MSVC compilation failures if the libs were enabled in meson.build. However, this code would still get compiled on Linux as usual, and hopefully we can enable all these libs once the patches get completed. I am aware that regressions can happen before that point. We will address them if that happens. It is tricky to handle so many paches/dependencies. Let me know if there's something that can be improved. Andre
[PATCH v3 1/2] usertools/devbind: update coding style
Devbind is one of the oldest tools in DPDK, and is written in a way that
uses a lot of string matching, no type safety, lots of global variables,
and has a few inconsistencies in the way it handles data (such as
differences between lspci calls and parsing in different circumstances).
This patch is a nigh complete rewrite of devbind, with full 100% feature
and command-line compatibility with the old version (except for dropping
older kernel support), albeit with a few differences in formatting and
error messages. All file handling code has also been replaced with
context managers.
What's different from old code:
- Full PEP-484 compliance
- Formatted with Ruff
- Much better structured code
- Clean and consistent control flow
- More comments
- Better error handling
- Fewer lspci calls
- Unified lspci parsing
- Using /sys/bus/pci/drivers as a source of truth about kernel modules
- Check for iproute2 package
- Use JSON parsing for iproute2 output
- Deprecate --status-dev in favor of optional --status argument
- Deprecate kernel <3.15 support and only use driver_override
Signed-off-by: Anatoly Burakov
Reviewed-By: Stephen Hemminger
---
Notes:
v2 - v3:
- Skip uninteresting routes reported by ip route
- Deduplicate active interface list
- Added missing documentation for no-IOMMU and UID/GID feature
- Slightly simplify device scanning
v1 -> v2:
- Use dictionary syntax to get raw string values from devices
- Fixed rollback not working correctly due to stale device state
- Fixed attempts to bind to empty driver on rollback
- Simplified bind/rollback and removed recursion
- Unified command-line and device type handling
- Dropped support for kernels <3.15
- Use JSON parsing for ip route output
- Used a new filename to aid in review, rename in next patch
doc/guides/tools/devbind.rst | 11 +
usertools/dpdk-devbind-new.py | 995 ++
2 files changed, 1006 insertions(+)
create mode 100755 usertools/dpdk-devbind-new.py
diff --git a/doc/guides/tools/devbind.rst b/doc/guides/tools/devbind.rst
index df4f3505ac..ef9ed44fea 100644
--- a/doc/guides/tools/devbind.rst
+++ b/doc/guides/tools/devbind.rst
@@ -56,6 +56,17 @@ OPTIONS
WARNING: This can lead to loss of network connection and should be used
with caution.
+* ``--noiommu-mode``
+
+When using vfio-pci driver on a system with no IOMMU, this flag should
be used to
+enable unsafe no-IOMMU mode for vfio-pci driver.
+
+* ``--uid uid, --gid gid``
+
+By default, devices which are bound to VFIO will be owned by ``root``.
+Use this flag to change ownership to the specified user and group, so
that
+devices bound to VFIO would be usable by unprivileged users.
+
.. warning::
diff --git a/usertools/dpdk-devbind-new.py b/usertools/dpdk-devbind-new.py
new file mode 100755
index 00..1f2d8cb118
--- /dev/null
+++ b/usertools/dpdk-devbind-new.py
@@ -0,0 +1,995 @@
+#!/usr/bin/env python3
+# SPDX-License-Identifier: BSD-3-Clause
+# Copyright(c) 2010-2024 Intel Corporation
+#
+"""Script to bind PCI devices to DPDK-compatible userspace IO drivers."""
+
+import argparse
+import glob
+import grp
+import json
+import os
+import pwd
+import subprocess
+import sys
+import typing as T
+
+# the following list of modules is supported by DPDK
+DPDK_KERNEL_MODULES = {"igb_uio", "vfio-pci", "uio_pci_generic"}
+
+# pattern matching criteria for various devices and devices classes. keys are
entries in lspci,
+# while values, if present are further matches for lspci criteria. values can
be either strings or
+# list of strings, in which case any match is sufficient.
+StrOrList = T.Union[str, T.List[str]]
+DeviceMatchPattern = T.Dict[str, StrOrList]
+CLASS_NETWORK: DeviceMatchPattern = {
+"Class": "02",
+}
+CLASS_ACCELERATION: DeviceMatchPattern = {
+"Class": "12",
+}
+CLASS_IFPGA: DeviceMatchPattern = {
+"Class": "12",
+"Vendor": "8086",
+"Device": "0b30",
+}
+CLASS_ENCRYPTION: DeviceMatchPattern = {
+"Class": "10",
+}
+CLASS_INTEL_PROCESSOR: DeviceMatchPattern = {
+"Class": "0b",
+"Vendor": "8086",
+}
+DEVICE_CAVIUM_SSO: DeviceMatchPattern = {
+"Class": "08",
+"Vendor": "177d",
+"Device": ["a04b", "a04d"],
+}
+DEVICE_CAVIUM_FPA: DeviceMatchPattern = {
+"Class": "08",
+"Vendor": "177d",
+"Device": "a053",
+}
+DEVICE_CAVIUM_PKX: DeviceMatchPattern = {
+"Class": "08",
+"Vendor": "177d",
+"Device": ["a0dd", "a049"],
+}
+DEVICE_CAVIUM_TIM: DeviceMatchPattern = {
+"Class": "08",
+"Vendor": "177d",
+"Device": "a051",
+}
+DEVICE_CAVIUM_ZIP: DeviceMatchPattern = {
+"Class": "12",
+"Vendor": "177d",
+"Device": "a037",
+}
+DEVICE_AVP_VNIC: DeviceMatchPattern = {
+"Class": "05",
+"Vendor": "1af4",
+"Device": "1110",
+}
+DEVICE_CNXK_BPHY: DeviceMatchPattern = {
+"Class": "08",
+"Vendor": "177d",
+"Device": "a089",
+}
+DEVICE_CNXK_BPHY
Re: [PATCH v6 08/30] drivers/common: replace packed attributes
On Tue, Nov 26, 2024 at 04:52:19PM -0800, Andre Muezerie wrote: > MSVC struct packing is not compatible with GCC. Replace macro > __rte_packed with __rte_packed_begin to push existing pack value > and set packing to 1-byte and macro __rte_packed_end to restore > the pack value prior to the push. > > Macro __rte_packed_end is deliberately utilized to trigger a > MSVC compiler warning if no existing packing has been pushed allowing > easy identification of locations where the __rte_packed_begin is > missing. > > Signed-off-by: Andre Muezerie > --- Reviewed-by: Tyler Retzlaff
Re: [PATCH v6 17/30] drivers/vdpa: replace packed attributes
On Tue, Nov 26, 2024 at 04:52:28PM -0800, Andre Muezerie wrote: > MSVC struct packing is not compatible with GCC. Replace macro > __rte_packed with __rte_packed_begin to push existing pack value > and set packing to 1-byte and macro __rte_packed_end to restore > the pack value prior to the push. > > Macro __rte_packed_end is deliberately utilized to trigger a > MSVC compiler warning if no existing packing has been pushed allowing > easy identification of locations where the __rte_packed_begin is > missing. > > Signed-off-by: Andre Muezerie > --- Reviewed-by: Tyler Retzlaff
Re: [PATCH v6 16/30] drivers/regex: replace packed attributes
On Tue, Nov 26, 2024 at 04:52:27PM -0800, Andre Muezerie wrote: > MSVC struct packing is not compatible with GCC. Replace macro > __rte_packed with __rte_packed_begin to push existing pack value > and set packing to 1-byte and macro __rte_packed_end to restore > the pack value prior to the push. > > Macro __rte_packed_end is deliberately utilized to trigger a > MSVC compiler warning if no existing packing has been pushed allowing > easy identification of locations where the __rte_packed_begin is > missing. > > Signed-off-by: Andre Muezerie > --- Reviewed-by: Tyler Retzlaff
