Re: [dpdk-dev] [PATCH V2 1/4] config/arm: add Hisilicon kunpeng920 implementer
在 2021/3/23 23:40, Ruifeng Wang 写道:
-Original Message-
From: oulijun
Sent: Tuesday, March 23, 2021 9:52 PM
To: Ruifeng Wang ; tho...@monjalon.net;
ferruh.yi...@intel.com
Cc: dev@dpdk.org; linux...@openeuler.org; nd
Subject: Re: [dpdk-dev] [PATCH V2 1/4] config/arm: add Hisilicon
kunpeng920 implementer
2021/3/23 16:07, Ruifeng Wang д :
-Original Message-
From: dev On Behalf Of Lijun Ou
Sent: Wednesday, March 10, 2021 9:36 AM
To: tho...@monjalon.net; ferruh.yi...@intel.com
Cc: dev@dpdk.org; linux...@openeuler.org
Subject: [dpdk-dev] [PATCH V2 1/4] config/arm: add Hisilicon
kunpeng920 implementer
Here addes Kunpeng920 config back which was deleted.
Fixes: 91c730fd4e09 ("config/arm: remove unused or superfluous
variables")
Signed-off-by: Chengchang Tang
Signed-off-by: Lijun Ou
---
V1->V2:
- rewrite patch title.
- split the patch into two.
---
config/arm/meson.build | 20
1 file changed, 20 insertions(+)
diff --git a/config/arm/meson.build b/config/arm/meson.build index
00bc461..3826900 100644
--- a/config/arm/meson.build
+++ b/config/arm/meson.build
@@ -133,6 +133,25 @@ implementer_cavium = {
}
}
+implementer_hisilicon = {
+ 'description': 'Hisilicon',
+ 'flags': [
+ ['RTE_USE_C11_MEM_MODEL', true],
+ ['RTE_CACHE_LINE_SIZE', 128],
Just want to double check.
One Kunpeng920 box I can access have cache line size 64B.
I have a question, which level does RTE_CACHE_LINE_SIZE refer to? For
kunpeng920, L1/L2 cache size is 64B L3 is 128B
Got it.
I think RTE_CACHE_LINE_SIZE is not defined for a certain level of cache.
Data can be prefetched into any level of cache by using different APIs.
So our current configuration should be fine.
Thanks.
+ ['RTE_MAX_NUMA_NODES', 4]
+ ],
+ 'part_number_config': {
+ '0xd01': {
+ 'machine_args': ['-march=armv8.2-a+crypto',
+'-mtune=tsv110'],
+ 'flag': [['RTE_MACHINE', '"kunpeng920"'],
+['RTE_MAX_LCORE', 128],
+['RTE_ARM_FEATURE_ATOMICS', true]
+ ]
+ }
+ }
+}
+
implementer_ampere = {
'description': 'Ampere Computing',
'flags': [
@@ -190,6 +209,7 @@ implementers = {
'generic': implementer_generic,
'0x41': implementer_arm,
'0x43': implementer_cavium,
+ '0x48': implementer_hisilicon,
'0x50': implementer_ampere,
'0x51': implementer_qualcomm,
'0x56': implementer_marvell,
--
2.7.4
.
Re: [dpdk-dev] [PATCH V2 1/4] config/arm: add Hisilicon kunpeng920 implementer
> -Original Message-
> From: oulijun
> Sent: Thursday, March 25, 2021 3:22 PM
> To: Ruifeng Wang ; tho...@monjalon.net;
> ferruh.yi...@intel.com
> Cc: dev@dpdk.org; linux...@openeuler.org; nd
> Subject: Re: [dpdk-dev] [PATCH V2 1/4] config/arm: add Hisilicon
> kunpeng920 implementer
>
>
>
> 在 2021/3/23 23:40, Ruifeng Wang 写道:
> >> -Original Message-
> >> From: oulijun
> >> Sent: Tuesday, March 23, 2021 9:52 PM
> >> To: Ruifeng Wang ; tho...@monjalon.net;
> >> ferruh.yi...@intel.com
> >> Cc: dev@dpdk.org; linux...@openeuler.org; nd
> >> Subject: Re: [dpdk-dev] [PATCH V2 1/4] config/arm: add Hisilicon
> >> kunpeng920 implementer
> >>
> >>
> >>
> >> 2021/3/23 16:07, Ruifeng Wang д :
> -Original Message-
> From: dev On Behalf Of Lijun Ou
> Sent: Wednesday, March 10, 2021 9:36 AM
> To: tho...@monjalon.net; ferruh.yi...@intel.com
> Cc: dev@dpdk.org; linux...@openeuler.org
> Subject: [dpdk-dev] [PATCH V2 1/4] config/arm: add Hisilicon
> kunpeng920 implementer
>
> Here addes Kunpeng920 config back which was deleted.
There was no Kunpeng920 specific config before change 91c730fd4e09.
It would fall back to generic build because the behavior was to do generic
build for unknown implementor / part number.
>
> Fixes: 91c730fd4e09 ("config/arm: remove unused or superfluous
> variables")
>
> Signed-off-by: Chengchang Tang
> Signed-off-by: Lijun Ou
> ---
> V1->V2:
> - rewrite patch title.
> - split the patch into two.
> ---
> config/arm/meson.build | 20
> 1 file changed, 20 insertions(+)
>
> diff --git a/config/arm/meson.build b/config/arm/meson.build index
> 00bc461..3826900 100644
> --- a/config/arm/meson.build
> +++ b/config/arm/meson.build
> @@ -133,6 +133,25 @@ implementer_cavium = {
> }
> }
>
> +implementer_hisilicon = {
> +'description': 'Hisilicon',
> +'flags': [
> +['RTE_USE_C11_MEM_MODEL', true],
> +['RTE_CACHE_LINE_SIZE', 128],
> >>>
> >>> Just want to double check.
> >>> One Kunpeng920 box I can access have cache line size 64B.
> >>>
> >> I have a question, which level does RTE_CACHE_LINE_SIZE refer to? For
> >> kunpeng920, L1/L2 cache size is 64B L3 is 128B
> >
> > Got it.
> > I think RTE_CACHE_LINE_SIZE is not defined for a certain level of cache.
> > Data can be prefetched into any level of cache by using different APIs.
> >
> So our current configuration should be fine.
Agree.
> >>> Thanks.
> +['RTE_MAX_NUMA_NODES', 4]
> +],
> +'part_number_config': {
> +'0xd01': {
> +'machine_args': ['-march=armv8.2-a+crypto',
> + '-mtune=tsv110'],
> +'flag': [['RTE_MACHINE', '"kunpeng920"'],
> + ['RTE_MAX_LCORE', 128],
> + ['RTE_ARM_FEATURE_ATOMICS', true]
> +]
> +}
> +}
> +}
> +
> implementer_ampere = {
> 'description': 'Ampere Computing',
> 'flags': [
> @@ -190,6 +209,7 @@ implementers = {
> 'generic': implementer_generic,
> '0x41': implementer_arm,
> '0x43': implementer_cavium,
> +'0x48': implementer_hisilicon,
> '0x50': implementer_ampere,
> '0x51': implementer_qualcomm,
> '0x56': implementer_marvell,
> --
> 2.7.4
> >>>
> >>> .
> >>>
Re: [dpdk-dev] [PATCH V2 3/4] config/arm: add kunpeng920 meson cross compile target
> -Original Message- > From: dev On Behalf Of Lijun Ou > Sent: Wednesday, March 10, 2021 9:36 AM > To: tho...@monjalon.net; ferruh.yi...@intel.com > Cc: dev@dpdk.org; linux...@openeuler.org > Subject: [dpdk-dev] [PATCH V2 3/4] config/arm: add kunpeng920 meson > cross compile target > > Here add arm64 cross compile support for Hisilicon kunpeng920. > > Signed-off-by: Chengchang Tang > Signed-off-by: Lijun Ou > --- > config/arm/arm64_kunpeng920_linux_gcc | 19 > +++ > doc/guides/linux_gsg/cross_build_dpdk_for_arm64.rst | 4 > 2 files changed, 23 insertions(+) > create mode 100644 config/arm/arm64_kunpeng920_linux_gcc > > diff --git a/config/arm/arm64_kunpeng920_linux_gcc > b/config/arm/arm64_kunpeng920_linux_gcc > new file mode 100644 > index 000..3eeb2e9 > --- /dev/null > +++ b/config/arm/arm64_kunpeng920_linux_gcc > @@ -0,0 +1,19 @@ > +[binaries] > +c = 'aarch64-linux-gnu-gcc' > +cpp = 'aarch64-linux-gnu-cpp' > +ar = 'aarch64-linux-gnu-gcc-ar' > +strip = 'aarch64-linux-gnu-strip' > +pkgconfig = 'aarch64-linux-gnu-pkg-config' > +pcap-config = '' > + > +[host_machine] > +system = 'linux' > +cpu_family = 'aarch64' > +cpu = 'armv8-a' > +endian = 'little' > + > +[properties] > +implementer_id = '0x48' > +part_number = '0xd01' > +max_lcores = 128 > +max_numa_nodes = 4 > diff --git a/doc/guides/linux_gsg/cross_build_dpdk_for_arm64.rst > b/doc/guides/linux_gsg/cross_build_dpdk_for_arm64.rst > index faaf24b..afe4f8e 100644 > --- a/doc/guides/linux_gsg/cross_build_dpdk_for_arm64.rst > +++ b/doc/guides/linux_gsg/cross_build_dpdk_for_arm64.rst > @@ -197,6 +197,7 @@ you may use various combinations of > implementer/part number:: >'generic': Generic armv8 >'0x41':Arm >'0x43':Cavium > + '0x48':Hisilicon >'0x50':Ampere Computing >'0x56':Marvell ARMADA >'dpaa':NXP DPAA > @@ -219,6 +220,9 @@ you may use various combinations of > implementer/part number:: >'0xaf':thunderx2t99 >'0xb2':octeontx2 > > + Supported part_numbers for 0x48: > + '0xd01':kunpeng920 > + > Supported part_numbers for 0x50: >'0x0': emag > > -- > 2.7.4 Reviewed-by: Ruifeng Wang
Re: [dpdk-dev] [PATCH V2 4/4] config/arm: add kunpeng930 meson cross compile target
> -Original Message- > From: dev On Behalf Of Lijun Ou > Sent: Wednesday, March 10, 2021 9:36 AM > To: tho...@monjalon.net; ferruh.yi...@intel.com > Cc: dev@dpdk.org; linux...@openeuler.org > Subject: [dpdk-dev] [PATCH V2 4/4] config/arm: add kunpeng930 meson > cross compile target > > Here add arm64 cross compile support for Hisilicon kunpeng930. > > Signed-off-by: Chengchang Tang > Signed-off-by: Lijun Ou > --- > config/arm/arm64_kunpeng930_linux_gcc | 19 > +++ > doc/guides/linux_gsg/cross_build_dpdk_for_arm64.rst | 1 + > 2 files changed, 20 insertions(+) > create mode 100644 config/arm/arm64_kunpeng930_linux_gcc > > diff --git a/config/arm/arm64_kunpeng930_linux_gcc > b/config/arm/arm64_kunpeng930_linux_gcc > new file mode 100644 > index 000..464e44a > --- /dev/null > +++ b/config/arm/arm64_kunpeng930_linux_gcc > @@ -0,0 +1,19 @@ > +[binaries] > +c = 'aarch64-linux-gnu-gcc' > +cpp = 'aarch64-linux-gnu-cpp' > +ar = 'aarch64-linux-gnu-gcc-ar' > +strip = 'aarch64-linux-gnu-strip' > +pkgconfig = 'aarch64-linux-gnu-pkg-config' > +pcap-config = '' > + > +[host_machine] > +system = 'linux' > +cpu_family = 'aarch64' > +cpu = 'armv8-a' > +endian = 'little' > + > +[properties] > +implementer_id = '0x48' > +part_number = '0xd02' > +max_lcores = 256 > +max_numa_nodes = 4 > diff --git a/doc/guides/linux_gsg/cross_build_dpdk_for_arm64.rst > b/doc/guides/linux_gsg/cross_build_dpdk_for_arm64.rst > index afe4f8e..1a54436 100644 > --- a/doc/guides/linux_gsg/cross_build_dpdk_for_arm64.rst > +++ b/doc/guides/linux_gsg/cross_build_dpdk_for_arm64.rst > @@ -222,6 +222,7 @@ you may use various combinations of > implementer/part number:: > > Supported part_numbers for 0x48: >'0xd01':kunpeng920 > + '0xd02':kunpeng930 > > Supported part_numbers for 0x50: >'0x0': emag > -- > 2.7.4 Reviewed-by: Ruifeng Wang
Re: [dpdk-dev] [PATCH v1] net/iavf: implement power management API
> -Original Message- > From: dev On Behalf Of Burakov, Anatoly > Sent: Thursday, March 11, 2021 9:37 PM > To: Hunt, David ; dev@dpdk.org > Cc: Wu, Jingjing ; Xing, Beilei > Subject: Re: [dpdk-dev] [PATCH v1] net/iavf: implement power management > API > > On 11-Mar-21 11:55 AM, David Hunt wrote: > > Implement support for the power management API by implementing a > > `get_monitor_addr` function that will return an address of an RX > > ring's status bit. > > > > This patch is basically a cut-and-paste of the changes already > > committed in ixgbe, i40e and ice drivers in 21.02. This extends the > > availability of the power-saving mechanism to the iavf driver, which > > is needed for those use-cases using virtual functions. > > > > Patch set where PMD Power Manamgement added in 21.02: > > http://patchwork.dpdk.org/project/dpdk/list/?series=14756 > > > > Signed-off-by: David Hunt > > --- > > LGTM as far as using the API correctly goes. > > Acked-by: Anatoly Burakov Applied to dpdk-next-net-intel. Thanks Qi
Re: [dpdk-dev] [PATCH V2 1/4] config/arm: add Hisilicon kunpeng920 implementer
在 2021/3/25 15:45, Ruifeng Wang 写道:
-Original Message-
From: oulijun
Sent: Thursday, March 25, 2021 3:22 PM
To: Ruifeng Wang ; tho...@monjalon.net;
ferruh.yi...@intel.com
Cc: dev@dpdk.org; linux...@openeuler.org; nd
Subject: Re: [dpdk-dev] [PATCH V2 1/4] config/arm: add Hisilicon
kunpeng920 implementer
在 2021/3/23 23:40, Ruifeng Wang 写道:
-Original Message-
From: oulijun
Sent: Tuesday, March 23, 2021 9:52 PM
To: Ruifeng Wang ; tho...@monjalon.net;
ferruh.yi...@intel.com
Cc: dev@dpdk.org; linux...@openeuler.org; nd
Subject: Re: [dpdk-dev] [PATCH V2 1/4] config/arm: add Hisilicon
kunpeng920 implementer
2021/3/23 16:07, Ruifeng Wang д :
-Original Message-
From: dev On Behalf Of Lijun Ou
Sent: Wednesday, March 10, 2021 9:36 AM
To: tho...@monjalon.net; ferruh.yi...@intel.com
Cc: dev@dpdk.org; linux...@openeuler.org
Subject: [dpdk-dev] [PATCH V2 1/4] config/arm: add Hisilicon
kunpeng920 implementer
Here addes Kunpeng920 config back which was deleted.
There was no Kunpeng920 specific config before change 91c730fd4e09.
It would fall back to generic build because the behavior was to do generic
build for unknown implementor / part number.
What should we do with this patch? This is because we cannot compile on
the Kunpeng 920 server without adding generic build.
Fixes: 91c730fd4e09 ("config/arm: remove unused or superfluous
variables")
Signed-off-by: Chengchang Tang
Signed-off-by: Lijun Ou
---
V1->V2:
- rewrite patch title.
- split the patch into two.
---
config/arm/meson.build | 20
1 file changed, 20 insertions(+)
diff --git a/config/arm/meson.build b/config/arm/meson.build index
00bc461..3826900 100644
--- a/config/arm/meson.build
+++ b/config/arm/meson.build
@@ -133,6 +133,25 @@ implementer_cavium = {
}
}
+implementer_hisilicon = {
+ 'description': 'Hisilicon',
+ 'flags': [
+ ['RTE_USE_C11_MEM_MODEL', true],
+ ['RTE_CACHE_LINE_SIZE', 128],
Just want to double check.
One Kunpeng920 box I can access have cache line size 64B.
I have a question, which level does RTE_CACHE_LINE_SIZE refer to? For
kunpeng920, L1/L2 cache size is 64B L3 is 128B
Got it.
I think RTE_CACHE_LINE_SIZE is not defined for a certain level of cache.
Data can be prefetched into any level of cache by using different APIs.
So our current configuration should be fine.
Agree.
Thanks.
+ ['RTE_MAX_NUMA_NODES', 4]
+ ],
+ 'part_number_config': {
+ '0xd01': {
+ 'machine_args': ['-march=armv8.2-a+crypto',
+'-mtune=tsv110'],
+ 'flag': [['RTE_MACHINE', '"kunpeng920"'],
+['RTE_MAX_LCORE', 128],
+['RTE_ARM_FEATURE_ATOMICS', true]
+ ]
+ }
+ }
+}
+
implementer_ampere = {
'description': 'Ampere Computing',
'flags': [
@@ -190,6 +209,7 @@ implementers = {
'generic': implementer_generic,
'0x41': implementer_arm,
'0x43': implementer_cavium,
+ '0x48': implementer_hisilicon,
'0x50': implementer_ampere,
'0x51': implementer_qualcomm,
'0x56': implementer_marvell,
--
2.7.4
.
Re: [dpdk-dev] [dpdk-stable] 答复: [PATCH] lib/librte_hash: add rte_hash_del_key_fixed without compact
25/03/2021 00:25, Wang, Yipeng1: > Hi, I reviewed my previous comment, I recall that this patch is an RFC for a > new API. > > The proposed API is not directly appliable for now since it discloses the > internals of the implementation to user. > > I am waiting for Jerry to post a new RFC, and more details of the use case to > motivate the change. > Thomas, you could change the status accordingly. Thanks, status updated: https://patches.dpdk.org/project/dpdk/patch/40280f65b1b0b44e8089ed31c01616eba4992...@dggeml529-mbx.china.huawei.com/ https://patches.dpdk.org/project/dpdk/patch/40280f65b1b0b44e8089ed31c01616eba4992...@dggeml529-mbx.china.huawei.com/
Re: [dpdk-dev] [PATCH] eal: standard c++ forbids defining the keyword asm as a macro
25/03/2021 01:09, Tyler Retzlaff: > On Thu, Mar 25, 2021 at 01:41:47AM +0300, Dmitry Kozlyuk wrote: > > 2021-03-24 14:55 (UTC-0700), Tyler Retzlaff: > > > > Can't speak for Seastar and Click, but we never hit this particular issue. > > What is the minimal complete example to reproduce? > > interesting, i did a bit more digging and it is clear why. i'm consuming > headers and crt that have been enhanced to enforce c++ standards > compliance. after dumping the preprocessed output i suspect this cannot > be reproduced with the publicly available headers it seems i'm the only > "beneficiary" heh. > > so the minimal example is really just to #include after including > say rte_windows.h but it won't reproduce for public users of the sdk. > > if there is a great deal of concern with respect to compatibility i > guess as the single consumer who has this problem i can just #undef asm > since we don't use inline asm anyway. > > thoughts? No please don't do this. There is an issue in DPDK which must be fixed. It seems your patch is correct, I am waiting for confirmation of others.
Re: [dpdk-dev] [PATCH] net/iavf: fix pkt len parsing in AVX512
> -Original Message-
> From: Coyle, David
> Sent: Wednesday, March 24, 2021 6:41 PM
> To: Rong, Leyi ; Zhang, Qi Z ; Lu,
> Wenzhuo ; Xing, Beilei
> Cc: dev@dpdk.org; Rong, Leyi
> Subject: RE: [dpdk-dev] [PATCH] net/iavf: fix pkt len parsing in AVX512
>
> Hi Leyi
>
> > -Original Message-
> > From: dev On Behalf Of Leyi Rong
> > Sent: Wednesday, March 17, 2021 9:18 AM
> > To: Zhang, Qi Z ; Lu, Wenzhuo
> > ; Xing, Beilei
> > Cc: dev@dpdk.org; Rong, Leyi
> > Subject: [dpdk-dev] [PATCH] net/iavf: fix pkt len parsing in AVX512
> >
> > Fix pkt_len parsing when DEV_RX_OFFLOAD_KEEP_CRC is set in AVX512
> > path.
> >
> > Fixes: 31737f2b66fb ("net/iavf: enable AVX512 for legacy Rx")
> > Fixes: 6df587028e57 ("net/iavf: enable AVX512 for flexible Rx")
> >
> > Signed-off-by: Leyi Rong
> > ---
> > drivers/net/iavf/iavf_rxtx_vec_avx512.c | 8
> > 1 file changed, 4 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/net/iavf/iavf_rxtx_vec_avx512.c
> > b/drivers/net/iavf/iavf_rxtx_vec_avx512.c
> > index 5cb4c7cda6..67184ae3f4 100644
> > --- a/drivers/net/iavf/iavf_rxtx_vec_avx512.c
> > +++ b/drivers/net/iavf/iavf_rxtx_vec_avx512.c
> > @@ -380,7 +380,7 @@ _iavf_recv_raw_pkts_vec_avx512(struct
> > iavf_rx_queue *rxq,
> > len4_7);
> > __m512i mb4_7 = _mm512_shuffle_epi8(desc4_7, shuf_msk);
> >
> > -mb4_7 = _mm512_add_epi16(mb4_7, crc_adjust);
> > +mb4_7 = _mm512_add_epi32(mb4_7, crc_adjust);
> > /**
> > * to get packet types, shift 64-bit values down 30 bits
> > * and so ptype is in lower 8-bits in each @@ -411,7 +411,7 @@
> > _iavf_recv_raw_pkts_vec_avx512(struct iavf_rx_queue *rxq, len0_3);
> > __m512i mb0_3 = _mm512_shuffle_epi8(desc0_3, shuf_msk);
> >
> > -mb0_3 = _mm512_add_epi16(mb0_3, crc_adjust);
> > +mb0_3 = _mm512_add_epi32(mb0_3, crc_adjust);
> > /* get the packet types */
> > const __m512i ptypes0_3 = _mm512_srli_epi64(desc0_3, 30); const
> > __m256i ptypes2_3 = _mm512_extracti64x4_epi64(ptypes0_3, 1); @@
> -869,7
> > +869,7 @@ _iavf_recv_raw_pkts_vec_avx512_flex_rxd(struct iavf_rx_queue
> > *rxq,
> > */
> > __m512i mb4_7 = _mm512_shuffle_epi8(raw_desc4_7, shuf_msk);
> >
> > -mb4_7 = _mm512_add_epi16(mb4_7, crc_adjust);
> > +mb4_7 = _mm512_add_epi32(mb4_7, crc_adjust);
> > /**
> > * to get packet types, ptype is located in bit16-25
> > * of each 128bits
> > @@ -898,7 +898,7 @@ _iavf_recv_raw_pkts_vec_avx512_flex_rxd(struct
> > iavf_rx_queue *rxq,
> > */
> > __m512i mb0_3 = _mm512_shuffle_epi8(raw_desc0_3, shuf_msk);
> >
> > -mb0_3 = _mm512_add_epi16(mb0_3, crc_adjust);
> > +mb0_3 = _mm512_add_epi32(mb0_3, crc_adjust);
> > /**
> > * to get packet types, ptype is located in bit16-25
> > * of each 128bits
> > --
> > 2.25.1
>
> This patch fixes the issue
>
> Tested-by: David Coyle
Applied to dpdk-next-net-intel
Thanks
Qi
Re: [dpdk-dev] [PATCH v1] lib/hash: support non sse42 cpu architecture
24/03/2021 23:59, Wang, Yipeng1:
> From: kumar amber
> >
> > add _SSE42_ flag to enable compilation of
> > sse42 specific instructions only on supported architecture
> >
> > Signed-off-by: kumar amber
> > ---
> > lib/librte_hash/rte_hash_crc.h | 16
> > 1 file changed, 8 insertions(+), 8 deletions(-)
> >
> > diff --git a/lib/librte_hash/rte_hash_crc.h b/lib/librte_hash/rte_hash_crc.h
> > index 3e131aa6bb..e9f063780c 100644
> > --- a/lib/librte_hash/rte_hash_crc.h
> > +++ b/lib/librte_hash/rte_hash_crc.h
> > @@ -358,7 +358,7 @@ crc32c_2words(uint64_t data, uint32_t init_val)
> > return crc;
> > }
> >
> > -#if defined(RTE_ARCH_X86)
> > +#if defined(RTE_ARCH_X86) && defined(__SSE42__)
> > static inline uint32_t
> > crc32c_sse42_u8(uint8_t data, uint32_t init_val) { @@ -404,7 +404,7 @@
> > crc32c_sse42_u64_mimic(uint64_t data, uint64_t init_val) } #endif
>
> ...
>
> > -#if defined RTE_ARCH_X86
> > +#if defined(RTE_ARCH_X86) && defined(__SSE42__)
> > if (likely(crc32_alg & CRC32_SSE42))
> > return crc32c_sse42_u64_mimic(data, init_val); #endif
> > --
> > 2.25.1
>
> [Wang, Yipeng]
> Hi, Kumar, thanks for the patch.
> I think the minimum required machine for x86 is sse4.2 compatible already. So
> I wonder if we really need this.
Yes, that's why I don't understand this patch.
> Also, I think the right way to check machine flag in DPDK should be:
> #If defined (RTE_MACHINE_CPUFLAG_SSE4_2)
These macros have been removed in DPDK 20.11.
> Instead of using compiler dependent macro.
Compiler macros are well standardized, it is OK.
Re: [dpdk-dev] [PATCH V2 1/4] config/arm: add Hisilicon kunpeng920 implementer
> -Original Message-
> From: oulijun
> Sent: Thursday, March 25, 2021 3:56 PM
> To: Ruifeng Wang ; tho...@monjalon.net;
> ferruh.yi...@intel.com
> Cc: dev@dpdk.org; linux...@openeuler.org; nd
> Subject: Re: [dpdk-dev] [PATCH V2 1/4] config/arm: add Hisilicon
> kunpeng920 implementer
>
>
>
> 在 2021/3/25 15:45, Ruifeng Wang 写道:
> >> -Original Message-
> >> From: oulijun
> >> Sent: Thursday, March 25, 2021 3:22 PM
> >> To: Ruifeng Wang ; tho...@monjalon.net;
> >> ferruh.yi...@intel.com
> >> Cc: dev@dpdk.org; linux...@openeuler.org; nd
> >> Subject: Re: [dpdk-dev] [PATCH V2 1/4] config/arm: add Hisilicon
> >> kunpeng920 implementer
> >>
> >>
> >>
> >> 在 2021/3/23 23:40, Ruifeng Wang 写道:
> -Original Message-
> From: oulijun
> Sent: Tuesday, March 23, 2021 9:52 PM
> To: Ruifeng Wang ; tho...@monjalon.net;
> ferruh.yi...@intel.com
> Cc: dev@dpdk.org; linux...@openeuler.org; nd
> Subject: Re: [dpdk-dev] [PATCH V2 1/4] config/arm: add Hisilicon
> kunpeng920 implementer
>
>
>
> 2021/3/23 16:07, Ruifeng Wang д :
> >> -Original Message-
> >> From: dev On Behalf Of Lijun Ou
> >> Sent: Wednesday, March 10, 2021 9:36 AM
> >> To: tho...@monjalon.net; ferruh.yi...@intel.com
> >> Cc: dev@dpdk.org; linux...@openeuler.org
> >> Subject: [dpdk-dev] [PATCH V2 1/4] config/arm: add Hisilicon
> >> kunpeng920 implementer
> >>
> >> Here addes Kunpeng920 config back which was deleted.
> >
> > There was no Kunpeng920 specific config before change 91c730fd4e09.
> > It would fall back to generic build because the behavior was to do generic
> build for unknown implementor / part number.
> >
> What should we do with this patch? This is because we cannot compile on
> the Kunpeng 920 server without adding generic build.
I see the need to add config for Kunpeng 920.
IMO, the commit message can be refined.
With commit message update,
Reviewed-by: Ruifeng Wang
> >>
> >> Fixes: 91c730fd4e09 ("config/arm: remove unused or superfluous
> >> variables")
> >>
> >> Signed-off-by: Chengchang Tang
> >> Signed-off-by: Lijun Ou
> >> ---
> >> V1->V2:
> >> - rewrite patch title.
> >> - split the patch into two.
> >> ---
> >> config/arm/meson.build | 20
> >> 1 file changed, 20 insertions(+)
> >>
> >> diff --git a/config/arm/meson.build b/config/arm/meson.build
> >> index
> >> 00bc461..3826900 100644
> >> --- a/config/arm/meson.build
> >> +++ b/config/arm/meson.build
> >> @@ -133,6 +133,25 @@ implementer_cavium = {
> >>}
> >> }
> >>
> >> +implementer_hisilicon = {
> >> + 'description': 'Hisilicon',
> >> + 'flags': [
> >> + ['RTE_USE_C11_MEM_MODEL', true],
> >> + ['RTE_CACHE_LINE_SIZE', 128],
> >
> > Just want to double check.
> > One Kunpeng920 box I can access have cache line size 64B.
> >
> I have a question, which level does RTE_CACHE_LINE_SIZE refer to?
> For kunpeng920, L1/L2 cache size is 64B L3 is 128B
> >>>
> >>> Got it.
> >>> I think RTE_CACHE_LINE_SIZE is not defined for a certain level of cache.
> >>> Data can be prefetched into any level of cache by using different APIs.
> >>>
> >> So our current configuration should be fine.
> >
> > Agree.
> >
> > Thanks.
> >> + ['RTE_MAX_NUMA_NODES', 4]
> >> + ],
> >> + 'part_number_config': {
> >> + '0xd01': {
> >> + 'machine_args': ['-march=armv8.2-a+crypto',
> >> + '-mtune=tsv110'],
> >> + 'flag': [['RTE_MACHINE', '"kunpeng920"'],
> >> + ['RTE_MAX_LCORE', 128],
> >> + ['RTE_ARM_FEATURE_ATOMICS',
> true]
> >> + ]
> >> + }
> >> + }
> >> +}
> >> +
> >> implementer_ampere = {
> >>'description': 'Ampere Computing',
> >>'flags': [
> >> @@ -190,6 +209,7 @@ implementers = {
> >>'generic': implementer_generic,
> >>'0x41': implementer_arm,
> >>'0x43': implementer_cavium,
> >> + '0x48': implementer_hisilicon,
> >>'0x50': implementer_ampere,
> >>'0x51': implementer_qualcomm,
> >>'0x56': implementer_marvell,
> >> --
> >> 2.7.4
> >
> > .
> >
Re: [dpdk-dev] [PATCH] examples/l3fwd: enable multiple Tx queues on a lcore
25/03/2021 06:38, Rong, Leyi: > From: Thomas Monjalon > > 05/11/2020 10:24, Rong, Leyi: > > > From: Jerin Jacob > > > > On Wed, Nov 4, 2020 at 2:34 PM Rong, Leyi wrote: > > > > > From: David Marchand > > > > > > On Wed, Nov 4, 2020 at 9:34 AM Rong, Leyi > > wrote: > > > > > > > As there always has thoughput limit for per queue, on some > > > > > > > performance test case by using l3fwd, the result will limited > > > > > > > by the per queue thoughput limit. With multiple Tx queue > > > > > > > enabled, the per queue thoughput limit can be eliminated if > > > > > > > the CPU core is not the bottleneck. > > > > > > > > > > > > Ah interesting. > > > > > > Which nic has such limitations? > > > > > > How much of an improvement can be expected from this? > > > > > > > > > > The initial found was on XXV710 25Gb NIC, but suppose such issue > > > > > can happen on more NICs as the high-end CPU per core boundary is > > > > > higher than many NICs(except 100Gb and above) per queue performance > > boundary. > > > > > The improvement can be about 1.8X with that case@1t2q. > > > > > > > > As far as I understand, the Current l3fwd Tx queue creation is like > > > > this: > > > > If the app has N cores and M ports then l3fwd creates, N x M Tx > > > > queues in total, What will be new values based on this patch? > > > > Thank you Jerin for providing some info missing in the description of the > > patch. > > > > > Hi Jacob, > > > > > > Total queues number equals to queues per port multiply port number. > > > Just take #l3fwd -l 5,6 -n 6 -- -p 0x3 --config > > > '(0,0,5),(0,1,5),(1,0,6),(1,1,6)' as example, With this patch appied, > > > totally 2x2=4 tx queues can be polled, while only > > > 1x2=2 tx queues can be used before. > > > > It does not reply above question with N x M. > > > > > > Does this patch has any regression in case the NIC queues able to > > > > cope up with the throughput limit from CPU. > > > > > > Regression test relevant with l3fwd passed with this patch, no obvious > > > result drop on other cases. > > > > It does not reply the general question for all drivers you did not test. > > > > As you probably noticed, this patch is blocked for months because it is not > > properly explained. > > > > Hi Thomas, > > This patch can be abandoned after synced with Konstantin months ago. And > update the state to superseded on patchwork, Thanks! "Superseded" means a newer version has been sent. I will change to "Rejected".
Re: [dpdk-dev] [PATCH] net/i40e: fix Virtchnl Offload Caps missing
> -Original Message-
> From: dev On Behalf Of Guo, Jia
> Sent: Friday, March 12, 2021 5:29 PM
> To: Zhang, RobinX ; dev@dpdk.org
> Cc: Xing, Beilei
> Subject: Re: [dpdk-dev] [PATCH] net/i40e: fix Virtchnl Offload Caps missing
>
> Acked-by: Jeff Guo
>
> > -Original Message-
> > From: Zhang, RobinX
> > Sent: Friday, March 12, 2021 4:52 PM
> > To: dev@dpdk.org
> > Cc: Xing, Beilei ; Guo, Jia
> > ; Zhang, RobinX
> > Subject: [PATCH] net/i40e: fix Virtchnl Offload Caps missing
> >
> > A new feature requesting additional queues from PF is added in iavf,
> > before sending VIRTCHNL_OP_REQUEST_QUEUES op code, the offload
> > capability flag VIRTCHNL_VF_OFFLOAD_REQ_QUEUES will be checked. And
> > due to DPDK PF is still used by some cases, so add this offload
> > capability flag in i40e pf.
> >
> > Fixes: cbdbd360f77f ("net/i40e: support AVF basic interface")
> >
> > Signed-off-by: Robin Zhang
> > ---
Applied to dpdk-next-net-intel.
Thanks
Qi
Re: [dpdk-dev] [PATCH v5 2/8] eventdev: introduce event vector Rx capability
> -Original Message-
> From: pbhagavat...@marvell.com
> Sent: Wednesday, March 24, 2021 10:35 AM
> To: jer...@marvell.com; Jayatheerthan, Jay ;
> Carrillo, Erik G ; Gujjar,
> Abhinandan S ; McDaniel, Timothy
> ; hemant.agra...@nxp.com; Van
> Haaren, Harry ; mattias.ronnblom
> ; Ma, Liang J
> ; Ray Kinsella ; Neil Horman
>
> Cc: dev@dpdk.org; Pavan Nikhilesh
> Subject: [dpdk-dev] [PATCH v5 2/8] eventdev: introduce event vector Rx
> capability
>
> From: Pavan Nikhilesh
>
> Introduce event ethernet Rx adapter event vector capability.
>
> If an event eth Rx adapter has the capability of
> RTE_EVENT_ETH_RX_ADAPTER_CAP_EVENT_VECTOR then a given Rx queue
> can be configured to enable event vectorization by passing the
> flag RTE_EVENT_ETH_RX_ADAPTER_QUEUE_EVENT_VECTOR to
> rte_event_eth_rx_adapter_queue_conf::rx_queue_flags while configuring
> Rx adapter through rte_event_eth_rx_adapter_queue_add().
>
> The max vector size, vector timeout define the vector size and
> mempool used for allocating vector event are configured through
> rte_event_eth_rx_adapter_queue_add. The element size of the element
> in the vector pool should be equal to
> sizeof(struct rte_event_vector) + (vector_sz * sizeof(uintptr_t))
>
> Application can use `rte_event_vector_pool_create` to create the
> vector mempool used for
> rte_event_eth_rx_adapter_queue_conf::vector_mp.
>
> The Rx adapter would be responsible for vectorizing the mbufs
> based on the flow, the vector limits configured by the application
> and add the vector event of mbufs to the event queue set via
> rte_event_eth_rx_adapter_queue_conf::ev::queue_id.
> It should also mark rte_event_vector::union_valid and fill
> rte_event_vector::port, rte_event_vector::queue.
>
> Signed-off-by: Pavan Nikhilesh
> Acked-by: Jerin Jacob
> ---
> .../prog_guide/event_ethernet_rx_adapter.rst | 38 ++
> lib/librte_eventdev/eventdev_pmd.h| 53
> .../rte_event_eth_rx_adapter.c| 114 ++
> .../rte_event_eth_rx_adapter.h| 105
> lib/librte_eventdev/rte_eventdev.h| 30 -
> lib/librte_eventdev/version.map | 2 +
> 6 files changed, 340 insertions(+), 2 deletions(-)
>
> diff --git a/doc/guides/prog_guide/event_ethernet_rx_adapter.rst
> b/doc/guides/prog_guide/event_ethernet_rx_adapter.rst
> index cb44ce0e4..5eefef355 100644
> --- a/doc/guides/prog_guide/event_ethernet_rx_adapter.rst
> +++ b/doc/guides/prog_guide/event_ethernet_rx_adapter.rst
> @@ -186,3 +186,41 @@ the event buffer fill level is low. The
> ``rte_event_eth_rx_adapter_cb_register()`` function allow the application
> to register a callback that selects which packets to enqueue to the event
> device.
> +
> +Rx event vectorization
> +~~
> +
> +The event devices, ethernet device pairs which support the capability
> +``RTE_EVENT_ETH_RX_ADAPTER_CAP_EVENT_VECTOR`` can aggregate packets based on
> +flow characteristics and generate a ``rte_event`` containing
> ``rte_event_vector``
> +whose event type is either ``RTE_EVENT_TYPE_ETHDEV_VECTOR`` or
> +``RTE_EVENT_TYPE_ETH_RX_ADAPTER_VECTOR``.
> +The aggregation size and timeout are configurable at a queue level and the
> +maximum, minimum vector sizes and timeouts vary based on the device
> capability
> +and can be queried using ``rte_event_eth_rx_adapter_vector_limits_get``.
> +The Rx adapter additionally might include useful data such as ethernet device
> +port and queue identifier in the ``rte_event_vector::port`` and
> +``rte_event_vector::queue`` and mark ``rte_event_vector::attr_valid`` as
> true.
> +
> +A loop processing ``rte_event_vector`` containing mbufs is shown below.
> +
> +.. code-block:: c
> +
> +event = rte_event_dequeue_burst(event_dev, event_port, &event,
> +1, 0);
> +if (!event)
> +continue;
> +
> +switch (ev.event_type) {
> +case RTE_EVENT_TYPE_ETH_RX_ADAPTER_VECTOR:
> +case RTE_EVENT_TYPE_ETHDEV_VECTOR:
> +struct rte_mbufs **mbufs;
> +
> +mbufs = (struct rte_mbufs **)ev[i].vec->mbufs;
> +for (i = 0; i < ev.vec->nb_elem; i++) {
> +/* Process each mbuf. */
> +}
> +break;
> +case ...
> +...
> +}
> diff --git a/lib/librte_eventdev/eventdev_pmd.h
> b/lib/librte_eventdev/eventdev_pmd.h
> index 7eb9a7739..9297f1433 100644
> --- a/lib/librte_eventdev/eventdev_pmd.h
> +++ b/lib/librte_eventdev/eventdev_pmd.h
> @@ -645,6 +645,53 @@ typedef int (*eventdev_eth_rx_adapter_stats_reset)
> */
> typedef int (*eventdev_selftest)(void);
>
> +struct rte_event_eth_rx_adapter_vector_limits;
> +/**
> + * Get event vector limits for a given event, ethernet device pair.
> + *
> + * @param dev
> + * Event device pointer
> + *
> + * @param eth_dev
> + * Ethernet device pointer
> + *
> + * @param[out] l
Re: [dpdk-dev] [PATCH v5 3/8] eventdev: introduce event vector Tx capability
> -Original Message-
> From: pbhagavat...@marvell.com
> Sent: Wednesday, March 24, 2021 10:35 AM
> To: jer...@marvell.com; Jayatheerthan, Jay ;
> Carrillo, Erik G ; Gujjar,
> Abhinandan S ; McDaniel, Timothy
> ; hemant.agra...@nxp.com; Van
> Haaren, Harry ; mattias.ronnblom
> ; Ma, Liang J
>
> Cc: dev@dpdk.org; Pavan Nikhilesh
> Subject: [dpdk-dev] [PATCH v5 3/8] eventdev: introduce event vector Tx
> capability
>
> From: Pavan Nikhilesh
>
> Introduce event vector transmit capability for event eth
> tx adapter.
>
> The capability indicates that the Tx adapter is capable of
> transmitting event vectors.
> When rte_event_vector::union_valid is set, the Tx adapter should
> transmit all the packets to the rte_event_vector::port using the
> rte_event_vector::queue.
> If rte_event_vector::union_valid is not set then the Tx adapter
> should peek into each mbuf to get the destination port and queue
> pair.
>
> Signed-off-by: Pavan Nikhilesh
> Acked-by: Jerin Jacob
> ---
> doc/guides/prog_guide/event_ethernet_tx_adapter.rst | 12
> lib/librte_eventdev/rte_eventdev.h | 8 +++-
> 2 files changed, 19 insertions(+), 1 deletion(-)
>
> diff --git a/doc/guides/prog_guide/event_ethernet_tx_adapter.rst
> b/doc/guides/prog_guide/event_ethernet_tx_adapter.rst
> index a8c13e136..87277dcaf 100644
> --- a/doc/guides/prog_guide/event_ethernet_tx_adapter.rst
> +++ b/doc/guides/prog_guide/event_ethernet_tx_adapter.rst
> @@ -164,3 +164,15 @@ The ``rte_event_eth_tx_adapter_stats_get()`` function
> reports counters defined
> in struct ``rte_event_eth_tx_adapter_stats``. The counter values are the sum
> of
> the counts from the eventdev PMD callback if the callback is supported, and
> the counts maintained by the service function, if one exists.
> +
> +Tx event vectorization
> +~~
> +
> +The event device, ethernet device paris which support the capability
Typo: "pairs" instead of "paris".
> +``RTE_EVENT_ETH_TX_ADAPTER_CAP_EVENT_VECTOR`` can process event vector of
> mbufs.
> +Additionally, application can provide a hint to that Tx adapter that all the
Typo: "hint to the Tx adapter" instead of "hint to that Tx adapter"
> +mbufs are destined to the same ethernet port and queue by setting the bit
> +``rte_event_vector::attr_valid`` and filling `rte_event_vector::port`` and
> +``rte_event_vector::queue``.
> +If ``rte_event_vector::attr_valid`` is not set then the Tx adapter should
> peek
> +into each mbuf and transmit them to the requested ethernet port and queue
> pair.
> diff --git a/lib/librte_eventdev/rte_eventdev.h
> b/lib/librte_eventdev/rte_eventdev.h
> index 678338247..67b681ef6 100644
> --- a/lib/librte_eventdev/rte_eventdev.h
> +++ b/lib/librte_eventdev/rte_eventdev.h
> @@ -927,11 +927,13 @@ struct rte_event_vector {
> /**< Indicates that the below union attributes have valid information.
>*/
> union {
> - /* Used by Rx adapter.
> + /* Used by Rx/Tx adapter.
>* Indicates that all the elements in this vector belong to the
>* same port and queue pair when originating from Rx adapter,
>* valid only when event type is ETHDEV_VECTOR or
>* ETH_RX_ADAPTER_VECTOR.
> + * Can also be used to indicate the Tx adapter the destination
> + * port and queue of the mbufs in the vector
>*/
> struct {
> uint16_t port;
> @@ -1293,6 +1295,10 @@ rte_event_crypto_adapter_caps_get(uint8_t dev_id,
> uint8_t cdev_id,
> #define RTE_EVENT_ETH_TX_ADAPTER_CAP_INTERNAL_PORT 0x1
> /**< This flag is sent when the PMD supports a packet transmit callback
> */
> +#define RTE_EVENT_ETH_TX_ADAPTER_CAP_EVENT_VECTOR0x2
> +/**< Indicates that the Tx adapter is capable of handling event vector of
> + * mbufs.
> + */
>
> /**
> * Retrieve the event device's eth Tx adapter capabilities
> --
> 2.17.1
With above changes, you can add Acked-by: Jay Jayatheerthan
.
Re: [dpdk-dev] [PATCH] net/igc: fix Rx RSS hash offload capabilities
> -Original Message-
> From: dev On Behalf Of Wang, Haiyue
> Sent: Thursday, March 25, 2021 10:52 AM
> To: Zhang, AlvinX ; Guo, Jia
> Cc: dev@dpdk.org; sta...@dpdk.org
> Subject: Re: [dpdk-dev] [PATCH] net/igc: fix Rx RSS hash offload capabilities
>
> > -Original Message-
> > From: Zhang, AlvinX
> > Sent: Thursday, March 25, 2021 09:52
> > To: Guo, Jia ; Wang, Haiyue
> > Cc: dev@dpdk.org; Zhang, AlvinX ;
> > sta...@dpdk.org
> > Subject: [PATCH] net/igc: fix Rx RSS hash offload capabilities
> >
> > Add DEV_RX_OFFLOAD_RSS_HASH flag to the PMD's Rx offload capabilities
> > for it supports RSS hash delivery.
> >
> > Fixes: 4f09bc55ac3d ("net/igc: implement device base operations")
> > Cc: sta...@dpdk.org
> >
> > Signed-off-by: Alvin Zhang
> > ---
> > drivers/net/igc/igc_ethdev.c | 3 +++
> > drivers/net/igc/igc_ethdev.h | 3 ++-
> > 2 files changed, 5 insertions(+), 1 deletion(-)
> >
>
> Acked-by: Haiyue Wang
Applied to dpdk-next-net-intel.
Thanks
Qi
Re: [dpdk-dev] [PATCH 2/2] [RFC]: ethdev: manage meter API object handles by the drivers
Hi Cristian From: Dumitrescu, Cristian > Hi Li and Matan, > > > -Original Message- > > From: Li Zhang > > Sent: Thursday, March 18, 2021 8:58 AM > > To: dek...@nvidia.com; or...@nvidia.com; viachesl...@nvidia.com; > > ma...@nvidia.com; shah...@nvidia.com; lir...@marvell.com; Singh, > > Jasvinder ; Thomas Monjalon > > ; Yigit, Ferruh ; Andrew > > Rybchenko ; Dumitrescu, Cristian > > > > Cc: dev@dpdk.org; rasl...@nvidia.com; ron...@nvidia.com > > Subject: [PATCH 2/2] [RFC]: ethdev: manage meter API object handles by > > the drivers > > > > Currently, all the meter objects are managed by the user IDs: > > meter, profile and policy. > > Hence, each PMD should manage data-structure in order to map each API > > ID to the private PMD management structure. > > > > From the application side, it has all the picture how meter is going > > to be assigned to flows and can easily use direct mapping even when > > the meter handler is provided by the PMDs. > > > > Also, this is the approach of the rte_flow API handles: > > the flow handle and the shared action handle is provided by the PMDs. > > > > Use drivers handlers in order to manage all the meter API objects. > > > > This seems to be take 2 of the discussion that we already had in this thread: > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmails.dp > dk.org%2Farchives%2Fdev%2F2021- > March%2F200710.html&data=04%7C01%7Cmatan%40nvidia.com%7Cab0 > e3cc77b9e4101344e08d8ee434bbe%7C43083d15727340c1b7db39efd9ccc17a% > 7C0%7C0%7C637521320105450617%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiM > C4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000& > amp;sdata=94bFRICfGEzk5s53MRUvFMQe5ZlhP2Tmnu82hwUytc4%3D&re > served=0, so apologies for mostly summarizing my previous feedback here. > > I am against this proposal because: > 1. We already discussed this topic of user-provided handles vs. > driver-provided > handles at length on this exact email list back in 2017, when we first > introduced > this API, and I don't see any real reason to revisit the decision we took > then. Why not? There is more experiences\usages now. New drivers added the support and also now scalability is growing and growing > 2. For me, it is more natural and it also helps the application to simplify > its data > structures if the user provides its own IDs rather than the user having to > deal > with the IDs provided by the driver. Generally I don't think other flow DPDK APIs align with your feelings here, see rte_flow object and rte_flow_shared_action. Specifically for meter: - here, meter is HW\driver offload where performance\rate either for meter creation\deletion or for the actual data-path is very important especially when we talk on very big numbers, so "natural" has less importance here. We need to think on the global solution for application ->API->driver. in meter feature, the user has the ability to manage the IDs better than the PMDs for the most of the use-cases: 1. meter per flow: just save the driver handle in the app flow context. 2. meter per VM\USER flows\rte_flow group\any other context grouped multiple flows: just save the driver handle in the app context. If PMD need to map the IDs, it is more complex for sure, requires more memory and more lookup time. - I'm not sure it is natural for all the use-cases, sometimes generating unique ID may complex the app. > 3. It is much easier and portable to pass numeric and string-based IDs around > (e.g. between processes) as opposed to pointer-based IDs, as pointers are only > valid in one address space and not in others. There are several DPDK APIs that > moved away from pointer handles to string IDs. Yes, I agree here generally. But again, since meter is used only by rte_flow, it is better to align the same handle mechanism. > 4. The mapping of user IDs to internal pointers within the driver is IMO not a > big issue in terms of memory footprint or API call rate. Matan also confirmed > this in the above thread when saying tis is not about either driver memory > footprint or API call speed, as this mapping is easy to optimize. Yes, it is not very big deal, but still costs more than the new suggestion, especially in big scale. > And last but not least, this change obviously propagates in every API > function, > so it would result in big churn in API, all drivers and all apps (including > testpmd, > etc) implementing it (for IMO no real benefit). Yes, this API is experimental > and > therefore we can operate changes in it, but I'd rather see incremental and > converging improvements rather than this. Yes, it changes all API, but very small part in each, will be very easy to align all the current dpdk components to use this concept. > If you guys insist with this proposal, I would like to get more opinions from > other vendors and contributors from within our DPDK community. Yes, more opinio
[dpdk-dev] [PATCH] eal/linux: add operation LOCK_NB to flock()
From: Tonghao Zhang
The hugepage of different size, 2MB, 1GB may be mounted on
the same directory (e.g /dev/hugepages). Then dpdk
primary process will be blocked. To address this issue,
add the LOCK_NB flags to flock().
$ cat /proc/mounts
...
none /dev/hugepages hugetlbfs rw,seclabel,relatime,pagesize=1024M 0 0
none /dev/hugepages hugetlbfs rw,seclabel,relatime,pagesize=2M 0 0
Add more details for err logs.
Signed-off-by: Tonghao Zhang
---
lib/librte_eal/linux/eal_hugepage_info.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/lib/librte_eal/linux/eal_hugepage_info.c
b/lib/librte_eal/linux/eal_hugepage_info.c
index d97792cadeb6..1ff76e539053 100644
--- a/lib/librte_eal/linux/eal_hugepage_info.c
+++ b/lib/librte_eal/linux/eal_hugepage_info.c
@@ -451,9 +451,12 @@ hugepage_info_init(void)
hpi->lock_descriptor = open(hpi->hugedir, O_RDONLY);
/* if blocking lock failed */
- if (flock(hpi->lock_descriptor, LOCK_EX) == -1) {
+ if (flock(hpi->lock_descriptor, LOCK_EX | LOCK_NB) == -1) {
RTE_LOG(CRIT, EAL,
- "Failed to lock hugepage directory!\n");
+ "Failed to lock hugepage directory! "
+ "The hugepage dir (%s) was locked by "
+ "other processes or self twice.\n",
+ hpi->hugedir);
break;
}
/* clear out the hugepages dir from unused pages */
--
2.27.0
Re: [dpdk-dev] [PATCH 1/4] net/virtio: fix interrupt unregistering for listening socket
On 3/17/21 9:25 PM, Ilya Maximets wrote:
> virtio_user_dev_server_reconnect() is typically called from the
> interrupt context while checking the link state:
>
> vhost_user_update_link_state()
> --> virtio_user_dev_server_reconnect()
>
> Under this conditions callback unregistering always fails. This means
> that listenfd is never unregistered and continue to trigger interrupts.
> For example, if second client will try to connect to the same socket,
> the server will receive interrupts infinitely because it will not
> accept them while listen fd is readable and generates epoll events.
>
> Fix that by moving reconfiguration of interrupts out of the
> interrupt context to alarm handler.
>
> 'virtio_user_dev_delayed_handler' renamed to
> 'virtio_user_dev_delayed_disconnect_handler' to better reflect its
> purpose.
>
> Additionally improved error logging around interrupt management.
>
> Fixes: bd8f50a45d0f ("net/virtio-user: support server mode")
> Cc: sta...@dpdk.org
>
> Signed-off-by: Ilya Maximets
> ---
>
> CC: Zhiyong Yang
>
> drivers/net/virtio/virtio_user/vhost_user.c | 4 +-
> .../net/virtio/virtio_user/virtio_user_dev.c | 70 ++-
> .../net/virtio/virtio_user/virtio_user_dev.h | 2 +-
> 3 files changed, 57 insertions(+), 19 deletions(-)
>
Reviewed-by: Maxime Coquelin
Thanks,
Maxime
Re: [dpdk-dev] [PATCH 2/3] examples/ipsec-secgw: add UDP encapsulation support
Hi Konstantin, Please see inline. Thanks Tejasree > -Original Message- > From: Ananyev, Konstantin > Sent: Wednesday, March 24, 2021 4:10 PM > To: Tejasree Kondoj ; Akhil Goyal > ; Nicolau, Radu > Cc: Anoob Joseph ; Ankur Dwivedi > ; Jerin Jacob Kollanukkaran ; > dev@dpdk.org > Subject: [EXT] RE: [dpdk-dev] [PATCH 2/3] examples/ipsec-secgw: add UDP > encapsulation support > > External Email > > -- > Hi Tejasree, > > > > > > > > > > Adding lookaside IPsec UDP encapsulation support for NAT > > > > > > > > > traversal. > > > > > > > > > Added --udp-encap option for application to specify if UDP > > > > > > > > > encapsulation need to be enabled. > > > > > > > > > Example secgw command with UDP encapsultation enabled: > > > > > > > > > -c 0x1 -- -P -p 0x1 --config "(0,0,0)" -f ep0.cfg > > > > > > > > > --udp-encap > > > > > > > > > > > > > > > > Can we have it not as global, but a per SA option? > > > > > > > > Add new keyword for SA/SP into ipsec-secgw config file, etc. > > > > > > > > Konstantin > > > > > > > > > > > > > > > > > > > > > > Any specific reason to make udp_encap as per SA? > > > > > > > UDP encapsulation is a feature which I believe should be > > > > > > > application > > > > vide. > > > > > > > If it supports the feature it should be enabled for all SAs when > > > > > > > the UDP > > > > port > > > > > > > is 4500 which is reserved for it. > > > > > > > > > > > > Not sure why it has to be application wide? > > > > > > Why it is not possible have let say SA1 in ipv4/ipv6 tunnel mode > > > > > > over port > > > > 0, > > > > > > and SA2 with udp encap over port 1? > > > > > > Note that in DPDK librte_security it is per SA option. > > > > > > > > > > UDP encapsulation can be done only if the UDP port is 4500 as per > > > > > the > > > > specification. > > > > > Please correct me if I am wrong. So if UDP port is NOT 4500 and > > > > > udp-encap > > > > is enabled in the > > > > > Command line, UDP encapsulation will not work. > > > > > > > > I am not asking you so support multiple UDP ports for IPsec > encapsulation. > > > > > > Multiple ports are not required to be supported as per specification. > > > UDP encapsulation work only on one port i.e. 4500. > > > By specification, it says, port 4500 is reserved for NAT traversal and if > > > a > > > Packet has this port, then it has to be processed accordingly. > > > > > > > What I am saying: it should be possible to use SAs with UDP > > > > encapsulation along with SAs without (plain tunnel/transport mode). > > > > > > Yes it is possible with the current patch. > > > If a packet has a UDP port = 4500 then it is UDP encapsulated otherwise it > is > > > not. > > > Hence, a packet with UDP port other than 4500 will work as it is working > > > without --udp-encap param. > > > > > > > As I understand with your patch it is not possible: if user specified > > > > --udp- encap all SAs (on all crypto-devs) will be treated as UDP > > > > encapsulated. > > > > > > Just to correct this statement. > > > > > > If user specified --udp-encap all SAs (on all crypto-devs) will be > > > treated as > > > UDP encapsulated if and only if the UDP port = 4500 and not otherwise. > > > > > > I hope this statement clears your concern and it makes more sense to > make it > > > application vide, just like esn and anti-replay. > > > > > > > [Tejasree] Just realized that all SAs are treated as UDP encapsulated > > if the packet type is other than UDP. Will add per SA support. > > > > Concern with per SA support: we cannot have "udp_encap==1" check in the > prepare_one_packet() > > function as SA info is not available at that time and plain UDP packets with > port 4500 are > > treated as IPsec and results could be unpredictable. > > If you think global udp_encap would be helpful (let say for > prepare_one_packet), > I think it is possible to keep it. By default it will be 0, and can be > initialized to > 1, > if we have at least one session with udp_encap enabled (after config file > parsing). > My thought about it was: > -prepare_packet() - mark both ip/esp and ip/udp(sport,dport=4500) as ESP > ones, > plus set mbuf.packet_type properly (UDP/ESP) (should we set l4_len also?). > - sad_lookup() - based on packet type (l4_len?) determine location of ESP > header > and do the lookup. Then if lookup was successful, for UDP packets check > does > SA.udp_encap==1. If no, then drop the packet. > > > > [Tejasree] l4_len setting is not needed. mbuf.packet_type can be used. Will send v2 with per SA support.
Re: [dpdk-dev] [PATCH] net/e1000: fix filter control return value
> -Original Message- > From: dev On Behalf Of Xiaozhen Ban > Sent: Friday, March 19, 2021 12:08 PM > To: Guo, Jia ; Wang, Haiyue > Cc: dev@dpdk.org; sta...@dpdk.org > Subject: Re: [dpdk-dev] [PATCH] net/e1000: fix filter control return value > > > > -Original Message- > > > From: Xiaozhen Ban > > > Sent: Thursday, March 18, 2021 19:44 > > > To: Guo, Jia ; Wang, Haiyue > > intel.com> > > > Cc: dev at dpdk.org; stable at dpdk.org > > > Subject: RE: RE: [PATCH] net/e1000: fix filter control return value > > > > > > OK, but I think this bug affects all stable release about 6 years before > > > today. > > > I don't think so, since it is PMD internal ops, the real API > > 'rte_flow_ops_get' > > always use RTE_ETH_FILTER_GENERIC. ;-) > > eth_igb_filter_ctrl() called by rte_eth_dev_filter_ctrl(), if application > developer > know how to use the parameter filter_type correctly, it's OK. > otherwise he will get rte_eth_dev_filter_ctrl() return value is success but > actually is failed. After check with Haiyue, we think the patch is still needed for LTS <= 19.11, so Acked-by: Qi Zhang Applied to dpdk-next-net-intel. Thanks Qi
Re: [dpdk-dev] [PATCH 0/2] adjusting mkey creations
Hi, > -Original Message- > From: Michael Baum > Sent: Thursday, March 18, 2021 11:56 AM > To: dev@dpdk.org > Cc: Matan Azrad ; Raslan Darawsheh > ; Slava Ovsiienko > Subject: [PATCH 0/2] adjusting mkey creations > > Adjusting mkey creations to use Verbs instead of DevX API. > > Michael Baum (2): > net/mlx5: workaround ASO memory region creation > net/mlx5: workaround counter memory region creation > > drivers/common/mlx5/linux/mlx5_common_verbs.c | 1 - > drivers/common/mlx5/windows/mlx5_common_os.c | 23 +++--- > drivers/net/mlx5/linux/mlx5_os.c | 10 --- > drivers/net/mlx5/mlx5.c | 11 ++- > drivers/net/mlx5/mlx5.h | 15 +--- > drivers/net/mlx5/mlx5_flow.c | 27 ++- > drivers/net/mlx5/mlx5_flow_age.c | 106 > +++--- > drivers/net/mlx5/windows/mlx5_os.c| 9 --- > 8 files changed, 71 insertions(+), 131 deletions(-) > > -- > 1.8.3.1 Series applied to next-net-mlx, Kindest regards, Raslan Darawsheh
[dpdk-dev] [PATCH] net/af_xdp: fix unchecked return of recvfrom()
Coverity complains that the return value of recvfrom() in the AF_XDP
datapath is not checked. We don't care about the return value because in
the case of an error we still return 0 from the receive function to
indicate no packets were received. So to make Coverity happy we cast the
return to 'void'.
Coverity issue: 369671
Fixes: 63e8989fe5a4 ("net/af_xdp: use recvfrom instead of poll syscall")
Signed-off-by: Ciara Loftus
---
drivers/net/af_xdp/rte_eth_af_xdp.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/af_xdp/rte_eth_af_xdp.c
b/drivers/net/af_xdp/rte_eth_af_xdp.c
index a64fef1cf5..6e44a21c64 100644
--- a/drivers/net/af_xdp/rte_eth_af_xdp.c
+++ b/drivers/net/af_xdp/rte_eth_af_xdp.c
@@ -274,7 +274,7 @@ af_xdp_rx_zc(void *queue, struct rte_mbuf **bufs, uint16_t
nb_pkts)
if (nb_pkts == 0) {
if (syscall_needed(&rxq->fq, rxq->busy_budget))
- recvfrom(xsk_socket__fd(rxq->xsk), NULL, 0,
+ (void)recvfrom(xsk_socket__fd(rxq->xsk), NULL, 0,
MSG_DONTWAIT, NULL, NULL);
return 0;
@@ -346,7 +346,7 @@ af_xdp_rx_cp(void *queue, struct rte_mbuf **bufs, uint16_t
nb_pkts)
if (nb_pkts == 0) {
#if defined(XDP_USE_NEED_WAKEUP)
if (xsk_ring_prod__needs_wakeup(fq))
- recvfrom(xsk_socket__fd(rxq->xsk), NULL, 0,
+ (void)recvfrom(xsk_socket__fd(rxq->xsk), NULL, 0,
MSG_DONTWAIT, NULL, NULL);
#endif
return 0;
--
2.17.1
Re: [dpdk-dev] [PATCH 0/4] telemetry logging improvements and cleanup
On Wed, Mar 24, 2021 at 10:11:55PM +0100, Thomas Monjalon wrote: > 10/03/2021 18:24, Bruce Richardson: > > This set adds support for using the regular rte_log functions from the > > telemetry > > library; avoiding circular dependencies by having EAL register the telemetry > > library itself and then passing the required handles to that library as > > part of > > the telemetry_init call. > > > > Beyond this change, the other three patches are cleanups to ensure that all > > internal functions are clearly separate from the public APIs. (Patches 3 & > > 4 may > > be merged into a single one on apply, for I've kept them separate for now > > for > > clarity). > > > > Bruce Richardson (4): > > telemetry: use rte_log for logging > > telemetry: make the legacy registration function internal > > telemetry: create internal-only header file > > telemetry: move init function to internal header > > Now that your patch "eal: fix querying DPDK version at runtime" > is in main branch, please could you rebase this series? > Sure, will do.
Re: [dpdk-dev] [PATCH v5 2/8] eventdev: introduce event vector Rx capability
>> From: pbhagavat...@marvell.com
>> Sent: Wednesday, March 24, 2021 10:35 AM
>> To: jer...@marvell.com; Jayatheerthan, Jay
>; Carrillo, Erik G
>; Gujjar,
>> Abhinandan S ; McDaniel, Timothy
>; hemant.agra...@nxp.com; Van
>> Haaren, Harry ; mattias.ronnblom
>; Ma, Liang J
>> ; Ray Kinsella ; Neil Horman
>
>> Cc: dev@dpdk.org; Pavan Nikhilesh
>> Subject: [dpdk-dev] [PATCH v5 2/8] eventdev: introduce event vector
>Rx capability
>>
>> From: Pavan Nikhilesh
>>
>> Introduce event ethernet Rx adapter event vector capability.
>>
>> If an event eth Rx adapter has the capability of
>> RTE_EVENT_ETH_RX_ADAPTER_CAP_EVENT_VECTOR then a given Rx
>queue
>> can be configured to enable event vectorization by passing the
>> flag RTE_EVENT_ETH_RX_ADAPTER_QUEUE_EVENT_VECTOR to
>> rte_event_eth_rx_adapter_queue_conf::rx_queue_flags while
>configuring
>> Rx adapter through rte_event_eth_rx_adapter_queue_add().
>>
>> The max vector size, vector timeout define the vector size and
>> mempool used for allocating vector event are configured through
>> rte_event_eth_rx_adapter_queue_add. The element size of the
>element
>> in the vector pool should be equal to
>> sizeof(struct rte_event_vector) + (vector_sz * sizeof(uintptr_t))
>>
>> Application can use `rte_event_vector_pool_create` to create the
>> vector mempool used for
>> rte_event_eth_rx_adapter_queue_conf::vector_mp.
>>
>> The Rx adapter would be responsible for vectorizing the mbufs
>> based on the flow, the vector limits configured by the application
>> and add the vector event of mbufs to the event queue set via
>> rte_event_eth_rx_adapter_queue_conf::ev::queue_id.
>> It should also mark rte_event_vector::union_valid and fill
>> rte_event_vector::port, rte_event_vector::queue.
>>
>> Signed-off-by: Pavan Nikhilesh
>> Acked-by: Jerin Jacob
>> ---
>> .../prog_guide/event_ethernet_rx_adapter.rst | 38 ++
>> lib/librte_eventdev/eventdev_pmd.h| 53
>> .../rte_event_eth_rx_adapter.c| 114 ++
>> .../rte_event_eth_rx_adapter.h| 105
>> lib/librte_eventdev/rte_eventdev.h| 30 -
>> lib/librte_eventdev/version.map | 2 +
>> 6 files changed, 340 insertions(+), 2 deletions(-)
>>
>> diff --git a/doc/guides/prog_guide/event_ethernet_rx_adapter.rst
>b/doc/guides/prog_guide/event_ethernet_rx_adapter.rst
>> index cb44ce0e4..5eefef355 100644
>> --- a/doc/guides/prog_guide/event_ethernet_rx_adapter.rst
>> +++ b/doc/guides/prog_guide/event_ethernet_rx_adapter.rst
>> @@ -186,3 +186,41 @@ the event buffer fill level is low. The
>> ``rte_event_eth_rx_adapter_cb_register()`` function allow the
>application
>> to register a callback that selects which packets to enqueue to the
>event
>> device.
>> +
>> +Rx event vectorization
>> +~~
>> +
>> +The event devices, ethernet device pairs which support the capability
>> +``RTE_EVENT_ETH_RX_ADAPTER_CAP_EVENT_VECTOR`` can
>aggregate packets based on
>> +flow characteristics and generate a ``rte_event`` containing
>``rte_event_vector``
>> +whose event type is either ``RTE_EVENT_TYPE_ETHDEV_VECTOR`` or
>> +``RTE_EVENT_TYPE_ETH_RX_ADAPTER_VECTOR``.
>> +The aggregation size and timeout are configurable at a queue level
>and the
>> +maximum, minimum vector sizes and timeouts vary based on the
>device capability
>> +and can be queried using
>``rte_event_eth_rx_adapter_vector_limits_get``.
>> +The Rx adapter additionally might include useful data such as
>ethernet device
>> +port and queue identifier in the ``rte_event_vector::port`` and
>> +``rte_event_vector::queue`` and mark
>``rte_event_vector::attr_valid`` as true.
>> +
>> +A loop processing ``rte_event_vector`` containing mbufs is shown
>below.
>> +
>> +.. code-block:: c
>> +
>> +event = rte_event_dequeue_burst(event_dev, event_port,
>&event,
>> +1, 0);
>> +if (!event)
>> +continue;
>> +
>> +switch (ev.event_type) {
>> +case RTE_EVENT_TYPE_ETH_RX_ADAPTER_VECTOR:
>> +case RTE_EVENT_TYPE_ETHDEV_VECTOR:
>> +struct rte_mbufs **mbufs;
>> +
>> +mbufs = (struct rte_mbufs **)ev[i].vec->mbufs;
>> +for (i = 0; i < ev.vec->nb_elem; i++) {
>> +/* Process each mbuf. */
>> +}
>> +break;
>> +case ...
>> +...
>> +}
>> diff --git a/lib/librte_eventdev/eventdev_pmd.h
>b/lib/librte_eventdev/eventdev_pmd.h
>> index 7eb9a7739..9297f1433 100644
>> --- a/lib/librte_eventdev/eventdev_pmd.h
>> +++ b/lib/librte_eventdev/eventdev_pmd.h
>> @@ -645,6 +645,53 @@ typedef int
>(*eventdev_eth_rx_adapter_stats_reset)
>> */
>> typedef int (*eventdev_selftest)(void);
>>
>> +struct rte_event_eth_rx_adapter_vector_limits;
>> +/**
>> + * Get event vector limits for a given event, ethernet device pair.
>> + *
>> + * @param dev
>> + * Event device pointer
>> + *
>> + * @param
Re: [dpdk-dev] [RFC 0/4] SocketPair Broker support for vhost and virtio-user.
On Wed, Mar 24, 2021 at 02:11:31PM +0100, Ilya Maximets wrote: > On 3/24/21 1:05 PM, Stefan Hajnoczi wrote: > > On Tue, Mar 23, 2021 at 04:54:57PM -0400, Billy McFall wrote: > >> On Tue, Mar 23, 2021 at 3:52 PM Ilya Maximets wrote: > >>> On 3/23/21 6:57 PM, Adrian Moreno wrote: > On 3/19/21 6:21 PM, Stefan Hajnoczi wrote: > > On Fri, Mar 19, 2021 at 04:29:21PM +0100, Ilya Maximets wrote: > >> On 3/19/21 3:05 PM, Stefan Hajnoczi wrote: > >>> On Thu, Mar 18, 2021 at 08:47:12PM +0100, Ilya Maximets wrote: > On 3/18/21 6:52 PM, Stefan Hajnoczi wrote: > > On Wed, Mar 17, 2021 at 09:25:26PM +0100, Ilya Maximets wrote: > - How to get this fd again after the OVS restart? CNI will not be invoked > at this point to pass a new fd. > > - If application will close the connection for any reason (restart, some > reconfiguration internal to the application) and OVS will be re-started > at the same time, abstract socket will be gone. Need a persistent daemon > to hold it. I remembered that these two points can be solved by sd_notify(3) FDSTORE=1. This requires that OVS runs as a systemd service. Not sure if this is the case (at least in the CNI use case)? https://www.freedesktop.org/software/systemd/man/sd_notify.html Stefan
Re: [dpdk-dev] [PATCH v5 2/8] eventdev: introduce event vector Rx capability
> -Original Message-
> From: Pavan Nikhilesh Bhagavatula
> Sent: Thursday, March 25, 2021 2:54 PM
> To: Jayatheerthan, Jay ; Jerin Jacob
> Kollanukkaran ; Carrillo, Erik G
> ; Gujjar, Abhinandan S
> ; McDaniel, Timothy
> ; hemant.agra...@nxp.com; Van Haaren, Harry
> ; mattias.ronnblom
> ; Ma, Liang J ; Ray
> Kinsella ; Neil Horman
>
> Cc: dev@dpdk.org
> Subject: RE: [dpdk-dev] [PATCH v5 2/8] eventdev: introduce event vector Rx
> capability
>
> >> From: pbhagavat...@marvell.com
> >> Sent: Wednesday, March 24, 2021 10:35 AM
> >> To: jer...@marvell.com; Jayatheerthan, Jay
> >; Carrillo, Erik G
> >; Gujjar,
> >> Abhinandan S ; McDaniel, Timothy
> >; hemant.agra...@nxp.com; Van
> >> Haaren, Harry ; mattias.ronnblom
> >; Ma, Liang J
> >> ; Ray Kinsella ; Neil Horman
> >
> >> Cc: dev@dpdk.org; Pavan Nikhilesh
> >> Subject: [dpdk-dev] [PATCH v5 2/8] eventdev: introduce event vector
> >Rx capability
> >>
> >> From: Pavan Nikhilesh
> >>
> >> Introduce event ethernet Rx adapter event vector capability.
> >>
> >> If an event eth Rx adapter has the capability of
> >> RTE_EVENT_ETH_RX_ADAPTER_CAP_EVENT_VECTOR then a given Rx
> >queue
> >> can be configured to enable event vectorization by passing the
> >> flag RTE_EVENT_ETH_RX_ADAPTER_QUEUE_EVENT_VECTOR to
> >> rte_event_eth_rx_adapter_queue_conf::rx_queue_flags while
> >configuring
> >> Rx adapter through rte_event_eth_rx_adapter_queue_add().
> >>
> >> The max vector size, vector timeout define the vector size and
> >> mempool used for allocating vector event are configured through
> >> rte_event_eth_rx_adapter_queue_add. The element size of the
> >element
> >> in the vector pool should be equal to
> >> sizeof(struct rte_event_vector) + (vector_sz * sizeof(uintptr_t))
> >>
> >> Application can use `rte_event_vector_pool_create` to create the
> >> vector mempool used for
> >> rte_event_eth_rx_adapter_queue_conf::vector_mp.
> >>
> >> The Rx adapter would be responsible for vectorizing the mbufs
> >> based on the flow, the vector limits configured by the application
> >> and add the vector event of mbufs to the event queue set via
> >> rte_event_eth_rx_adapter_queue_conf::ev::queue_id.
> >> It should also mark rte_event_vector::union_valid and fill
> >> rte_event_vector::port, rte_event_vector::queue.
> >>
> >> Signed-off-by: Pavan Nikhilesh
> >> Acked-by: Jerin Jacob
> >> ---
> >> .../prog_guide/event_ethernet_rx_adapter.rst | 38 ++
> >> lib/librte_eventdev/eventdev_pmd.h| 53
> >> .../rte_event_eth_rx_adapter.c| 114 ++
> >> .../rte_event_eth_rx_adapter.h| 105
> >> lib/librte_eventdev/rte_eventdev.h| 30 -
> >> lib/librte_eventdev/version.map | 2 +
> >> 6 files changed, 340 insertions(+), 2 deletions(-)
> >>
> >> diff --git a/doc/guides/prog_guide/event_ethernet_rx_adapter.rst
> >b/doc/guides/prog_guide/event_ethernet_rx_adapter.rst
> >> index cb44ce0e4..5eefef355 100644
> >> --- a/doc/guides/prog_guide/event_ethernet_rx_adapter.rst
> >> +++ b/doc/guides/prog_guide/event_ethernet_rx_adapter.rst
> >> @@ -186,3 +186,41 @@ the event buffer fill level is low. The
> >> ``rte_event_eth_rx_adapter_cb_register()`` function allow the
> >application
> >> to register a callback that selects which packets to enqueue to the
> >event
> >> device.
> >> +
> >> +Rx event vectorization
> >> +~~
> >> +
> >> +The event devices, ethernet device pairs which support the capability
> >> +``RTE_EVENT_ETH_RX_ADAPTER_CAP_EVENT_VECTOR`` can
> >aggregate packets based on
> >> +flow characteristics and generate a ``rte_event`` containing
> >``rte_event_vector``
> >> +whose event type is either ``RTE_EVENT_TYPE_ETHDEV_VECTOR`` or
> >> +``RTE_EVENT_TYPE_ETH_RX_ADAPTER_VECTOR``.
> >> +The aggregation size and timeout are configurable at a queue level
> >and the
> >> +maximum, minimum vector sizes and timeouts vary based on the
> >device capability
> >> +and can be queried using
> >``rte_event_eth_rx_adapter_vector_limits_get``.
> >> +The Rx adapter additionally might include useful data such as
> >ethernet device
> >> +port and queue identifier in the ``rte_event_vector::port`` and
> >> +``rte_event_vector::queue`` and mark
> >``rte_event_vector::attr_valid`` as true.
> >> +
> >> +A loop processing ``rte_event_vector`` containing mbufs is shown
> >below.
> >> +
> >> +.. code-block:: c
> >> +
> >> +event = rte_event_dequeue_burst(event_dev, event_port,
> >&event,
> >> +1, 0);
> >> +if (!event)
> >> +continue;
> >> +
> >> +switch (ev.event_type) {
> >> +case RTE_EVENT_TYPE_ETH_RX_ADAPTER_VECTOR:
> >> +case RTE_EVENT_TYPE_ETHDEV_VECTOR:
> >> +struct rte_mbufs **mbufs;
> >> +
> >> +mbufs = (struct rte_mbufs **)ev[i].vec->mbufs;
> >> +for (i = 0; i < ev.vec->nb_elem; i++) {
> >> +
Re: [dpdk-dev] [PATCH v3 2/2] drivers/net: remove explicit include of legacy filtering
On 3/25/2021 5:53 AM, Andrew Rybchenko wrote: On 3/24/21 11:00 PM, Thomas Monjalon wrote: 24/03/2021 19:08, Ferruh Yigit: On 3/21/2021 9:00 AM, Thomas Monjalon wrote: The header file rte_eth_ctrl.h should not be needed because this legacy filtering API is completely replaced with the rte_flow API. However some definitions from this file are still used by some drivers, but such usage is already covered by an implicit include via rte_ethdev.h. Signed-off-by: Thomas Monjalon Acked-by: Rosen Xu Acked-by: Hemant Agrawal --- drivers/net/dpaa2/dpaa2_ptp.c | 1 - drivers/net/iavf/iavf_hash.c| 1 - drivers/net/ice/ice_acl_filter.c| 1 - drivers/net/ice/ice_hash.c | 1 - drivers/net/ice/ice_switch_filter.c | 1 - drivers/net/igc/igc_filter.h| 1 - drivers/net/ipn3ke/ipn3ke_flow.c| 1 - Although this will work, if the above drives are using the defines from the header file, isn't it better to include it explicitly? What is the benefit of including the header implicitly? The benefit is to progressively remove rte_eth_ctrl.h. I want it to disappear. +1 This is just hiding its usage, the patch is not making it less used as a step forward to remove it. But anyway I guess it doesn't worth spending more time to discuss it ...
Re: [dpdk-dev] [PATCH] ethdev: add queue state when retrieve queue information
在 2021/3/22 23:45, Ananyev, Konstantin 写道:
-Original Message-
From: dev On Behalf Of Andrew Rybchenko
Sent: Monday, March 22, 2021 2:49 PM
To: Yigit, Ferruh ; Lijun Ou ;
tho...@monjalon.net
Cc: dev@dpdk.org; linux...@openeuler.org; Andrew Rybchenko
; David Marchand
; Ray Kinsella ; Luca Boccassi
Subject: Re: [dpdk-dev] [PATCH] ethdev: add queue state when retrieve queue
information
On 3/22/21 12:22 PM, Ferruh Yigit wrote:
On 3/18/2021 12:25 PM, Lijun Ou wrote:
Currently, upper-layer application could get queue state only
through pointers such as dev->data->tx_queue_state[queue_id],
this is not the recommended way to access it. So this patch
add get queue state when call rte_eth_rx_queue_info_get and
rte_eth_tx_queue_info_get API.
Note: The hairpin queue is not supported with above
rte_eth_*x_queue_info_get, so the queue state could be
RTE_ETH_QUEUE_STATE_STARTED or RTE_ETH_QUEUE_STATE_STOPPED.
Note: After add queue_state field, the 'struct rte_eth_rxq_info' size
remains 128B, and the 'struct rte_eth_txq_info' size remains 64B, so
it could be ABI compatible.
Signed-off-by: Chengwen Feng
Signed-off-by: Lijun Ou
<...>
diff --git a/lib/librte_ethdev/rte_ethdev.h
b/lib/librte_ethdev/rte_ethdev.h
index efda313..3b83c5a 100644
--- a/lib/librte_ethdev/rte_ethdev.h
+++ b/lib/librte_ethdev/rte_ethdev.h
@@ -1591,6 +1591,8 @@ struct rte_eth_rxq_info {
uint8_t scattered_rx; /**< scattered packets RX supported. */
uint16_t nb_desc; /**< configured number of RXDs. */
uint16_t rx_buf_size; /**< hardware receive buffer size. */
+/**< Queues state: STARTED(1) / STOPPED(0). */
+uint8_t queue_state;
} __rte_cache_min_aligned;
/**
@@ -1600,6 +1602,8 @@ struct rte_eth_rxq_info {
struct rte_eth_txq_info {
struct rte_eth_txconf conf; /**< queue config parameters. */
uint16_t nb_desc; /**< configured number of TXDs. */
+/**< Queues state: STARTED(1) / STOPPED(0). */
+uint8_t queue_state;
} __rte_cache_min_aligned;
/* Generic Burst mode flag definition, values can be ORed. */
This is causing an ABI warning [1], but I guess it is safe since the
size of the struct is not changing (cache align). Adding a few more
people to comment.
[1]
https://travis-ci.com/github/ovsrobot/dpdk/builds/220497651
Frankly speaking I dislike addition of queue_state as uint8_t.
IMHO it should be either 'bool started' or enum to support more
states in the future if we need.
I think we already have set of defines for it:
lib/librte_ethdev/rte_ethdev_driver.h:925:#define RTE_ETH_QUEUE_STATE_STOPPED 0
lib/librte_ethdev/rte_ethdev_driver.h:926:#define RTE_ETH_QUEUE_STATE_STARTED 1
lib/librte_ethdev/rte_ethdev_driver.h:927:#define RTE_ETH_QUEUE_STATE_HAIRPIN 2
At the latest date, the rte_ethdev_driver.h file does not exist.
If we want to publish it, then might be enough just move these macros to
rte_ethdev.h or so.
About uint8_t vs enum - yes, in principle enum would be a bit nicer,
but right now rte_eth_dev_data.(rx|tx)_queue_state[] itself is an array of
uint8_t.
So probably not much point to waste extra 3B in rte_eth_(rxq|txq)_info.
Unless in future will want to change it in struct rte_eth_dev_data too
(or even hide it inside dev private queue data).
Re: [dpdk-dev] [PATCH] ethdev: add queue state when retrieve queue information
>
>
> 在 2021/3/22 23:45, Ananyev, Konstantin 写道:
> >
> >
> >> -Original Message-
> >> From: dev On Behalf Of Andrew Rybchenko
> >> Sent: Monday, March 22, 2021 2:49 PM
> >> To: Yigit, Ferruh ; Lijun Ou ;
> >> tho...@monjalon.net
> >> Cc: dev@dpdk.org; linux...@openeuler.org; Andrew Rybchenko
> >> ; David Marchand
> >> ; Ray Kinsella ; Luca Boccassi
> >>
> >> Subject: Re: [dpdk-dev] [PATCH] ethdev: add queue state when retrieve
> >> queue information
> >>
> >> On 3/22/21 12:22 PM, Ferruh Yigit wrote:
> >>> On 3/18/2021 12:25 PM, Lijun Ou wrote:
> Currently, upper-layer application could get queue state only
> through pointers such as dev->data->tx_queue_state[queue_id],
> this is not the recommended way to access it. So this patch
> add get queue state when call rte_eth_rx_queue_info_get and
> rte_eth_tx_queue_info_get API.
>
> Note: The hairpin queue is not supported with above
> rte_eth_*x_queue_info_get, so the queue state could be
> RTE_ETH_QUEUE_STATE_STARTED or RTE_ETH_QUEUE_STATE_STOPPED.
> Note: After add queue_state field, the 'struct rte_eth_rxq_info' size
> remains 128B, and the 'struct rte_eth_txq_info' size remains 64B, so
> it could be ABI compatible.
>
> Signed-off-by: Chengwen Feng
> Signed-off-by: Lijun Ou
> >>>
> >>> <...>
> >>>
> diff --git a/lib/librte_ethdev/rte_ethdev.h
> b/lib/librte_ethdev/rte_ethdev.h
> index efda313..3b83c5a 100644
> --- a/lib/librte_ethdev/rte_ethdev.h
> +++ b/lib/librte_ethdev/rte_ethdev.h
> @@ -1591,6 +1591,8 @@ struct rte_eth_rxq_info {
> uint8_t scattered_rx; /**< scattered packets RX supported.
> */
> uint16_t nb_desc; /**< configured number of RXDs. */
> uint16_t rx_buf_size; /**< hardware receive buffer size. */
> +/**< Queues state: STARTED(1) / STOPPED(0). */
> +uint8_t queue_state;
> } __rte_cache_min_aligned;
> /**
> @@ -1600,6 +1602,8 @@ struct rte_eth_rxq_info {
> struct rte_eth_txq_info {
> struct rte_eth_txconf conf; /**< queue config parameters. */
> uint16_t nb_desc; /**< configured number of TXDs. */
> +/**< Queues state: STARTED(1) / STOPPED(0). */
> +uint8_t queue_state;
> } __rte_cache_min_aligned;
> /* Generic Burst mode flag definition, values can be ORed. */
>
> >>>
> >>> This is causing an ABI warning [1], but I guess it is safe since the
> >>> size of the struct is not changing (cache align). Adding a few more
> >>> people to comment.
> >>>
> >>>
> >>> [1]
> >>> https://travis-ci.com/github/ovsrobot/dpdk/builds/220497651
> >>
> >> Frankly speaking I dislike addition of queue_state as uint8_t.
> >> IMHO it should be either 'bool started' or enum to support more
> >> states in the future if we need.
> >
> > I think we already have set of defines for it:
> > lib/librte_ethdev/rte_ethdev_driver.h:925:#define
> > RTE_ETH_QUEUE_STATE_STOPPED 0
> > lib/librte_ethdev/rte_ethdev_driver.h:926:#define
> > RTE_ETH_QUEUE_STATE_STARTED 1
> > lib/librte_ethdev/rte_ethdev_driver.h:927:#define
> > RTE_ETH_QUEUE_STATE_HAIRPIN 2
> At the latest date, the rte_ethdev_driver.h file does not exist.
Yep, It was renamed to ethdev_driver.h.
But the defines are still there.
> >
> > If we want to publish it, then might be enough just move these macros to
> > rte_ethdev.h or so.
> >
> > About uint8_t vs enum - yes, in principle enum would be a bit nicer,
> > but right now rte_eth_dev_data.(rx|tx)_queue_state[] itself is an array of
> > uint8_t.
> > So probably not much point to waste extra 3B in rte_eth_(rxq|txq)_info.
> > Unless in future will want to change it in struct rte_eth_dev_data too
> > (or even hide it inside dev private queue data).
> >
> >
> >
Re: [dpdk-dev] [PATCH v3 3/7] net/txgbe: update link setup process of backplane NICs
On 3/25/2021 5:51 AM, Jiawen Wu wrote:
Add device arguments to support runtime options.
And use these configuration to control the link setup flow, to adapt to
different NIC's construction. Use firmware version to control the impact
of firmware update. And fix some left bugs.
Signed-off-by: Jiawen Wu
<...>
+#define TXGBE_DEBUG_BP
+#ifdef TXGBE_DEBUG_BP
+#define BP_LOG(fmt, ...) \
+ RTE_LOG(CRIT, PMD, "[%lu.%lu]%s(%d): " fmt, \
+ usec_stamp() / 100, usec_stamp() % 100, \
+ __func__, __LINE__, ## __VA_ARGS__)
+#else
+#define BP_LOG(fmt, ...) do { } while (0)
+#endif
+
#endif /* _TXGBE_LOGS_H_ */
The 'BP_LOG' looks like used for developer debug prints, if so I suggest
removing them completely,
but if not can you please convert it dynamic logging, or using existing dynamic
logs 'txgbe_logtype_init', 'txgbe_logtype_driver'?
Thanks,
ferruh
Re: [dpdk-dev] [PATCH v3 2/2] drivers/net: remove explicit include of legacy filtering
25/03/2021 11:00, Ferruh Yigit: > On 3/25/2021 5:53 AM, Andrew Rybchenko wrote: > > On 3/24/21 11:00 PM, Thomas Monjalon wrote: > >> 24/03/2021 19:08, Ferruh Yigit: > >>> On 3/21/2021 9:00 AM, Thomas Monjalon wrote: > The header file rte_eth_ctrl.h should not be needed because > this legacy filtering API is completely replaced with the rte_flow API. > However some definitions from this file are still used by some drivers, > but such usage is already covered by an implicit include via > rte_ethdev.h. > > Signed-off-by: Thomas Monjalon > Acked-by: Rosen Xu > Acked-by: Hemant Agrawal > --- > drivers/net/dpaa2/dpaa2_ptp.c | 1 - > drivers/net/iavf/iavf_hash.c| 1 - > drivers/net/ice/ice_acl_filter.c| 1 - > drivers/net/ice/ice_hash.c | 1 - > drivers/net/ice/ice_switch_filter.c | 1 - > drivers/net/igc/igc_filter.h| 1 - > drivers/net/ipn3ke/ipn3ke_flow.c| 1 - > >>> > >>> Although this will work, if the above drives are using the defines from > >>> the > >>> header file, isn't it better to include it explicitly? > >>> > >>> What is the benefit of including the header implicitly? > >> > >> The benefit is to progressively remove rte_eth_ctrl.h. > >> I want it to disappear. > >> > > > > +1 > > > > This is just hiding its usage, the patch is not making it less used as a step > forward to remove it. Yes you're right. The only step forward is esthetic: hiding something which should be removed. And maybe some of these files don't need the include at all. > But anyway I guess it doesn't worth spending more time to discuss it ... Feel free to reject if you feel it is not a good step.
Re: [dpdk-dev] [PATCH v5 4/8] eventdev: add Rx adapter event vector support
> -Original Message-
> From: pbhagavat...@marvell.com
> Sent: Wednesday, March 24, 2021 10:35 AM
> To: jer...@marvell.com; Jayatheerthan, Jay ;
> Carrillo, Erik G ; Gujjar,
> Abhinandan S ; McDaniel, Timothy
> ; hemant.agra...@nxp.com; Van
> Haaren, Harry ; mattias.ronnblom
> ; Ma, Liang J
>
> Cc: dev@dpdk.org; Pavan Nikhilesh
> Subject: [dpdk-dev] [PATCH v5 4/8] eventdev: add Rx adapter event vector
> support
>
> From: Pavan Nikhilesh
>
> Add event vector support for event eth Rx adapter, the implementation
> creates vector flows based on port and queue identifier of the received
> mbufs.
>
> Signed-off-by: Pavan Nikhilesh
> ---
> lib/librte_eventdev/eventdev_pmd.h| 7 +-
> .../rte_event_eth_rx_adapter.c| 257 --
> lib/librte_eventdev/rte_eventdev.c| 6 +-
> 3 files changed, 250 insertions(+), 20 deletions(-)
>
> diff --git a/lib/librte_eventdev/eventdev_pmd.h
> b/lib/librte_eventdev/eventdev_pmd.h
> index 9297f1433..0f724ac85 100644
> --- a/lib/librte_eventdev/eventdev_pmd.h
> +++ b/lib/librte_eventdev/eventdev_pmd.h
> @@ -69,9 +69,10 @@ extern "C" {
> } \
> } while (0)
>
> -#define RTE_EVENT_ETH_RX_ADAPTER_SW_CAP \
> - ((RTE_EVENT_ETH_RX_ADAPTER_CAP_OVERRIDE_FLOW_ID) | \
> - (RTE_EVENT_ETH_RX_ADAPTER_CAP_MULTI_EVENTQ))
> +#define RTE_EVENT_ETH_RX_ADAPTER_SW_CAP
> \
> + ((RTE_EVENT_ETH_RX_ADAPTER_CAP_OVERRIDE_FLOW_ID) | \
> + (RTE_EVENT_ETH_RX_ADAPTER_CAP_MULTI_EVENTQ) | \
> + (RTE_EVENT_ETH_RX_ADAPTER_CAP_EVENT_VECTOR))
>
> #define RTE_EVENT_CRYPTO_ADAPTER_SW_CAP \
> RTE_EVENT_CRYPTO_ADAPTER_CAP_SESSION_PRIVATE_DATA
> diff --git a/lib/librte_eventdev/rte_event_eth_rx_adapter.c
> b/lib/librte_eventdev/rte_event_eth_rx_adapter.c
> index ac8ba5bf0..c71990078 100644
> --- a/lib/librte_eventdev/rte_event_eth_rx_adapter.c
> +++ b/lib/librte_eventdev/rte_event_eth_rx_adapter.c
> @@ -26,6 +26,10 @@
> #define BATCH_SIZE 32
> #define BLOCK_CNT_THRESHOLD 10
> #define ETH_EVENT_BUFFER_SIZE(4*BATCH_SIZE)
> +#define MAX_VECTOR_SIZE 1024
> +#define MIN_VECTOR_SIZE 4
> +#define MAX_VECTOR_NS1E9
> +#define MIN_VECTOR_NS1E5
>
> #define ETH_RX_ADAPTER_SERVICE_NAME_LEN 32
> #define ETH_RX_ADAPTER_MEM_NAME_LEN 32
> @@ -59,6 +63,20 @@ struct eth_rx_poll_entry {
> uint16_t eth_rx_qid;
> };
>
> +struct eth_rx_vector_data {
> + TAILQ_ENTRY(eth_rx_vector_data) next;
> + uint16_t port;
> + uint16_t queue;
> + uint16_t max_vector_count;
> + uint64_t event;
> + uint64_t ts;
> + uint64_t vector_timeout_ticks;
> + struct rte_mempool *vector_pool;
> + struct rte_event_vector *vector_ev;
> +} __rte_cache_aligned;
> +
> +TAILQ_HEAD(eth_rx_vector_data_list, eth_rx_vector_data);
> +
> /* Instance per adapter */
> struct rte_eth_event_enqueue_buffer {
> /* Count of events in this buffer */
> @@ -92,6 +110,14 @@ struct rte_event_eth_rx_adapter {
> uint32_t wrr_pos;
> /* Event burst buffer */
> struct rte_eth_event_enqueue_buffer event_enqueue_buffer;
> + /* Vector enable flag */
> + uint8_t ena_vector;
> + /* Timestamp of previous vector expiry list traversal */
> + uint64_t prev_expiry_ts;
> + /* Minimum ticks to wait before traversing expiry list */
> + uint64_t vector_tmo_ticks;
> + /* vector list */
> + struct eth_rx_vector_data_list vector_list;
> /* Per adapter stats */
> struct rte_event_eth_rx_adapter_stats stats;
> /* Block count, counts up to BLOCK_CNT_THRESHOLD */
> @@ -198,9 +224,11 @@ struct eth_device_info {
> struct eth_rx_queue_info {
> int queue_enabled; /* True if added */
> int intr_enabled;
> + uint8_t ena_vector;
> uint16_t wt;/* Polling weight */
> uint32_t flow_id_mask; /* Set to ~0 if app provides flow id else 0 */
> uint64_t event;
> + struct eth_rx_vector_data vector_data;
> };
>
> static struct rte_event_eth_rx_adapter **event_eth_rx_adapter;
> @@ -722,6 +750,9 @@ rxa_flush_event_buffer(struct rte_event_eth_rx_adapter
> *rx_adapter)
> &rx_adapter->event_enqueue_buffer;
> struct rte_event_eth_rx_adapter_stats *stats = &rx_adapter->stats;
>
> + if (!buf->count)
> + return 0;
> +
> uint16_t n = rte_event_enqueue_new_burst(rx_adapter->eventdev_id,
> rx_adapter->event_port_id,
> buf->events,
> @@ -742,6 +773,72 @@ rxa_flush_event_buffer(struct rte_event_eth_rx_adapter
> *rx_adapter)
> return n;
> }
>
> +static inline uint16_t
> +rxa_create_event_vector(struct rte_event_eth_rx_adapter *rx_adapter,
> + struct eth_rx_queue_info *queue_info,
> + struct rte_eth_eve
Re: [dpdk-dev] [PATCH 1/7] common/octeontx: enable build only on 64bit Linux
24/03/2021 11:55, Jerin Jacob: > On Thu, Feb 25, 2021 at 10:33 PM wrote: > > > > From: Pavan Nikhilesh > > > > Due to Linux kernel dependency, only enable build for 64bit Linux. > > > > Signed-off-by: Pavan Nikhilesh > > > Series Acked-by: Jerin Jacob I've reorganized the commits per family of drivers, so it makes more sense than grouping per driver class with "common/octeontx" for title for all: net/thunderx: enable build only on 64-bit Linux common/octeontx: enable build only on 64-bit Linux common/octeontx2: enable build only on 64-bit Linux and applied.
Re: [dpdk-dev] [PATCH 1/7] common/octeontx: enable build only on 64bit Linux
25/03/2021 11:42, Thomas Monjalon: > 24/03/2021 11:55, Jerin Jacob: > > On Thu, Feb 25, 2021 at 10:33 PM wrote: > > > > > > From: Pavan Nikhilesh > > > > > > Due to Linux kernel dependency, only enable build for 64bit Linux. > > > > > > Signed-off-by: Pavan Nikhilesh > > > > Series Acked-by: Jerin Jacob > > I've reorganized the commits per family of drivers, > so it makes more sense than grouping per driver class > with "common/octeontx" for title for all: > > net/thunderx: enable build only on 64-bit Linux > common/octeontx: enable build only on 64-bit Linux > common/octeontx2: enable build only on 64-bit Linux > > and applied. Actually not applied yet. I'm not sure what to do for the ABI check which is broken because some drivers are not compiled anymore in 32-bit build. I've workarounded locally by removing the dump files in the reference build. Should we add an exception in libabigail.abignore?
[dpdk-dev] [PATCH v2] When fragmenting ipv4 packet, the data offset should be calculated through the ihl field in ip header rather than using sizeof(struct rte_ipv4_hdr).
From: Pu Xu <583493...@qq.com>
Signed-off-by: Pu Xu <583493...@qq.com>
---
lib/librte_ip_frag/rte_ipv4_fragmentation.c | 34 +
1 file changed, 21 insertions(+), 13 deletions(-)
diff --git a/lib/librte_ip_frag/rte_ipv4_fragmentation.c
b/lib/librte_ip_frag/rte_ipv4_fragmentation.c
index e9de335ae..2e7739d02 100644
--- a/lib/librte_ip_frag/rte_ipv4_fragmentation.c
+++ b/lib/librte_ip_frag/rte_ipv4_fragmentation.c
@@ -23,10 +23,10 @@
#defineIPV4_HDR_FO_ALIGN (1 <<
RTE_IPV4_HDR_FO_SHIFT)
static inline void __fill_ipv4hdr_frag(struct rte_ipv4_hdr *dst,
- const struct rte_ipv4_hdr *src, uint16_t len, uint16_t fofs,
- uint16_t dofs, uint32_t mf)
+ const struct rte_ipv4_hdr *src, uint16_t header_len,
+ uint16_t len, uint16_t fofs, uint16_t dofs, uint32_t mf)
{
- rte_memcpy(dst, src, sizeof(*dst));
+ rte_memcpy(dst, src, header_len);
fofs = (uint16_t)(fofs + (dofs >> RTE_IPV4_HDR_FO_SHIFT));
fofs = (uint16_t)(fofs | mf << RTE_IPV4_HDR_MF_SHIFT);
dst->fragment_offset = rte_cpu_to_be_16(fofs);
@@ -74,7 +74,7 @@ rte_ipv4_fragment_packet(struct rte_mbuf *pkt_in,
struct rte_ipv4_hdr *in_hdr;
uint32_t out_pkt_pos, in_seg_data_pos;
uint32_t more_in_segs;
- uint16_t fragment_offset, flag_offset, frag_size;
+ uint16_t fragment_offset, flag_offset, frag_size, header_len;
uint16_t frag_bytes_remaining;
/*
@@ -86,14 +86,22 @@ rte_ipv4_fragment_packet(struct rte_mbuf *pkt_in,
unlikely(mtu_size < RTE_ETHER_MIN_MTU))
return -EINVAL;
+ in_hdr = rte_pktmbuf_mtod(pkt_in, struct rte_ipv4_hdr *);
+ header_len = (in_hdr->version_ihl & RTE_IPV4_HDR_IHL_MASK) *
+ RTE_IPV4_IHL_MULTIPLIER;
+
+ /* Check IP header length */
+ if (unlikely(pkt_in->data_len < header_len) ||
+ unlikely(mtu_size < header_len))
+ return -EINVAL;
+
/*
* Ensure the IP payload length of all fragments is aligned to a
* multiple of 8 bytes as per RFC791 section 2.3.
*/
- frag_size = RTE_ALIGN_FLOOR((mtu_size - sizeof(struct rte_ipv4_hdr)),
+ frag_size = RTE_ALIGN_FLOOR((mtu_size - header_len),
IPV4_HDR_FO_ALIGN);
- in_hdr = rte_pktmbuf_mtod(pkt_in, struct rte_ipv4_hdr *);
flag_offset = rte_cpu_to_be_16(in_hdr->fragment_offset);
/* If Don't Fragment flag is set */
@@ -102,11 +110,11 @@ rte_ipv4_fragment_packet(struct rte_mbuf *pkt_in,
/* Check that pkts_out is big enough to hold all fragments */
if (unlikely(frag_size * nb_pkts_out <
- (uint16_t)(pkt_in->pkt_len - sizeof(struct rte_ipv4_hdr
+ (uint16_t)(pkt_in->pkt_len - header_len)))
return -EINVAL;
in_seg = pkt_in;
- in_seg_data_pos = sizeof(struct rte_ipv4_hdr);
+ in_seg_data_pos = header_len;
out_pkt_pos = 0;
fragment_offset = 0;
@@ -124,8 +132,8 @@ rte_ipv4_fragment_packet(struct rte_mbuf *pkt_in,
}
/* Reserve space for the IP header that will be built later */
- out_pkt->data_len = sizeof(struct rte_ipv4_hdr);
- out_pkt->pkt_len = sizeof(struct rte_ipv4_hdr);
+ out_pkt->data_len = header_len;
+ out_pkt->pkt_len = header_len;
frag_bytes_remaining = frag_size;
out_seg_prev = out_pkt;
@@ -176,14 +184,14 @@ rte_ipv4_fragment_packet(struct rte_mbuf *pkt_in,
out_hdr = rte_pktmbuf_mtod(out_pkt, struct rte_ipv4_hdr *);
- __fill_ipv4hdr_frag(out_hdr, in_hdr,
+ __fill_ipv4hdr_frag(out_hdr, in_hdr, header_len,
(uint16_t)out_pkt->pkt_len,
flag_offset, fragment_offset, more_in_segs);
fragment_offset = (uint16_t)(fragment_offset +
- out_pkt->pkt_len - sizeof(struct rte_ipv4_hdr));
+ out_pkt->pkt_len - header_len);
- out_pkt->l3_len = sizeof(struct rte_ipv4_hdr);
+ out_pkt->l3_len = header_len;
/* Write the fragment to the output list */
pkts_out[out_pkt_pos] = out_pkt;
--
2.17.0
Re: [dpdk-dev] [PATCH 1/7] common/octeontx: enable build only on 64bit Linux
On 25/03/2021 10:46, Thomas Monjalon wrote: > 25/03/2021 11:42, Thomas Monjalon: >> 24/03/2021 11:55, Jerin Jacob: >>> On Thu, Feb 25, 2021 at 10:33 PM wrote: From: Pavan Nikhilesh Due to Linux kernel dependency, only enable build for 64bit Linux. Signed-off-by: Pavan Nikhilesh >>> >>> Series Acked-by: Jerin Jacob >> >> I've reorganized the commits per family of drivers, >> so it makes more sense than grouping per driver class >> with "common/octeontx" for title for all: >> >> net/thunderx: enable build only on 64-bit Linux >> common/octeontx: enable build only on 64-bit Linux >> common/octeontx2: enable build only on 64-bit Linux >> >> and applied. > > Actually not applied yet. > I'm not sure what to do for the ABI check which is broken > because some drivers are not compiled anymore in 32-bit build. > I've workarounded locally by removing the dump files in the reference build. > Should we add an exception in libabigail.abignore? > In the past we said that depreciating HW support would be considered to be same as an ABI Breakage. >From the policy ... "Updates to the minimum hardware requirements, which drop support for hardware which was previously supported, should be treated as an ABI change."
Re: [dpdk-dev] [RFC 0/4] SocketPair Broker support for vhost and virtio-user.
On 3/25/21 10:35 AM, Stefan Hajnoczi wrote: > On Wed, Mar 24, 2021 at 02:11:31PM +0100, Ilya Maximets wrote: >> On 3/24/21 1:05 PM, Stefan Hajnoczi wrote: >>> On Tue, Mar 23, 2021 at 04:54:57PM -0400, Billy McFall wrote: On Tue, Mar 23, 2021 at 3:52 PM Ilya Maximets wrote: > On 3/23/21 6:57 PM, Adrian Moreno wrote: >> On 3/19/21 6:21 PM, Stefan Hajnoczi wrote: >>> On Fri, Mar 19, 2021 at 04:29:21PM +0100, Ilya Maximets wrote: On 3/19/21 3:05 PM, Stefan Hajnoczi wrote: > On Thu, Mar 18, 2021 at 08:47:12PM +0100, Ilya Maximets wrote: >> On 3/18/21 6:52 PM, Stefan Hajnoczi wrote: >>> On Wed, Mar 17, 2021 at 09:25:26PM +0100, Ilya Maximets wrote: >> - How to get this fd again after the OVS restart? CNI will not be invoked >> at this point to pass a new fd. >> >> - If application will close the connection for any reason (restart, some >> reconfiguration internal to the application) and OVS will be re-started >> at the same time, abstract socket will be gone. Need a persistent daemon >> to hold it. > > I remembered that these two points can be solved by sd_notify(3) > FDSTORE=1. This requires that OVS runs as a systemd service. Not sure if > this is the case (at least in the CNI use case)? > > https://www.freedesktop.org/software/systemd/man/sd_notify.html IIUC, these file descriptors only passed on the restart of the service, so port-del + port-add scenario is not covered (and this is a very common usecase, users are implementing some configuration changes this way and also this is internally possible scenario, e.g. this sequence will be triggered internally to change the OpenFlow port number). port-del will release all the resources including the listening socket. Keeping the fd for later use is not an option, because OVS will not know if this port will be added back or not and fds is a limited resource. It's also unclear how to map these file descriptors to particular ports they belong to after restart. OVS could run as a system pod or as a systemd service. It differs from one setup to another. So it might not be controlled by systemd. Also, it behaves as an old-style daemon, so it closes all the file descriptors, forkes and so on. This might be adjusted, though, with some rework of the deamonization procedure. On the side note, it maybe interesting to allow user application to create a socket and pass a pollable file descriptor directly to rte_vhost_driver_register() instead of a socket path. This way the user application may choose to use an abstract socket or a file socket or any other future type of socket connections. This will also allow user application to store these sockets somewhere, or receive them from systemd/init/other management software. Best regards, Ilya Maximets.
Re: [dpdk-dev] [PATCH 1/7] common/octeontx: enable build only on 64bit Linux
25/03/2021 11:58, Kinsella, Ray: > On 25/03/2021 10:46, Thomas Monjalon wrote: > > 25/03/2021 11:42, Thomas Monjalon: > >> 24/03/2021 11:55, Jerin Jacob: > >>> On Thu, Feb 25, 2021 at 10:33 PM wrote: > > From: Pavan Nikhilesh > > Due to Linux kernel dependency, only enable build for 64bit Linux. > > Signed-off-by: Pavan Nikhilesh > >>> > >>> Series Acked-by: Jerin Jacob > >> > >> I've reorganized the commits per family of drivers, > >> so it makes more sense than grouping per driver class > >> with "common/octeontx" for title for all: > >> > >> net/thunderx: enable build only on 64-bit Linux > >> common/octeontx: enable build only on 64-bit Linux > >> common/octeontx2: enable build only on 64-bit Linux > >> > >> and applied. > > > > Actually not applied yet. > > I'm not sure what to do for the ABI check which is broken > > because some drivers are not compiled anymore in 32-bit build. > > I've workarounded locally by removing the dump files in the reference build. > > Should we add an exception in libabigail.abignore? > > > In the past we said that depreciating HW support would be considered to be > same as an ABI Breakage. > > From the policy ... > "Updates to the minimum hardware requirements, which drop support for > hardware which was previously supported, should be treated as an ABI change." So the patches should wait 21.11. Everybody agree?
[dpdk-dev] [PATCH V2] ethdev: add queue state when retrieve queue information
Currently, upper-layer application could get queue state only
through pointers such as dev->data->tx_queue_state[queue_id],
this is not the recommended way to access it. So this patch
add get queue state when call rte_eth_rx_queue_info_get and
rte_eth_tx_queue_info_get API.
Note: The hairpin queue is not supported with above
rte_eth_*x_queue_info_get, so the queue state could be
RTE_ETH_QUEUE_STATE_STARTED or RTE_ETH_QUEUE_STATE_STOPPED.
Note: After add queue_state field, the 'struct rte_eth_rxq_info' size
remains 128B, and the 'struct rte_eth_txq_info' size remains 64B, so
it could be ABI compatible.
Signed-off-by: Chengwen Feng
Signed-off-by: Lijun Ou
---
V1->V2:
- move queue state defines to public file
---
doc/guides/rel_notes/release_21_05.rst | 6 ++
lib/librte_ethdev/ethdev_driver.h | 7 ---
lib/librte_ethdev/rte_ethdev.c | 3 +++
lib/librte_ethdev/rte_ethdev.h | 11 +++
4 files changed, 20 insertions(+), 7 deletions(-)
diff --git a/doc/guides/rel_notes/release_21_05.rst
b/doc/guides/rel_notes/release_21_05.rst
index 22aa80a..503daf9 100644
--- a/doc/guides/rel_notes/release_21_05.rst
+++ b/doc/guides/rel_notes/release_21_05.rst
@@ -164,6 +164,12 @@ ABI Changes
* No ABI change that would break compatibility with 20.11.
+* Added new field ``queue_state`` to ``rte_eth_rxq_info`` structure
+ to provide indicated rxq queue state.
+
+* Added new field ``queue_state`` to ``rte_eth_txq_info`` structure
+ to provide indicated txq queue state.
+
Known Issues
diff --git a/lib/librte_ethdev/ethdev_driver.h
b/lib/librte_ethdev/ethdev_driver.h
index cdd4b43..ec5a17d 100644
--- a/lib/librte_ethdev/ethdev_driver.h
+++ b/lib/librte_ethdev/ethdev_driver.h
@@ -970,13 +970,6 @@ struct eth_dev_ops {
};
/**
- * RX/TX queue states
- */
-#define RTE_ETH_QUEUE_STATE_STOPPED 0
-#define RTE_ETH_QUEUE_STATE_STARTED 1
-#define RTE_ETH_QUEUE_STATE_HAIRPIN 2
-
-/**
* @internal
* Check if the selected Rx queue is hairpin queue.
*
diff --git a/lib/librte_ethdev/rte_ethdev.c b/lib/librte_ethdev/rte_ethdev.c
index 3059aa5..fbd10b2 100644
--- a/lib/librte_ethdev/rte_ethdev.c
+++ b/lib/librte_ethdev/rte_ethdev.c
@@ -5042,6 +5042,8 @@ rte_eth_rx_queue_info_get(uint16_t port_id, uint16_t
queue_id,
memset(qinfo, 0, sizeof(*qinfo));
dev->dev_ops->rxq_info_get(dev, queue_id, qinfo);
+ qinfo->queue_state = dev->data->rx_queue_state[queue_id];
+
return 0;
}
@@ -5082,6 +5084,7 @@ rte_eth_tx_queue_info_get(uint16_t port_id, uint16_t
queue_id,
memset(qinfo, 0, sizeof(*qinfo));
dev->dev_ops->txq_info_get(dev, queue_id, qinfo);
+ qinfo->queue_state = dev->data->tx_queue_state[queue_id];
return 0;
}
diff --git a/lib/librte_ethdev/rte_ethdev.h b/lib/librte_ethdev/rte_ethdev.h
index efda313..4f0b1b2 100644
--- a/lib/librte_ethdev/rte_ethdev.h
+++ b/lib/librte_ethdev/rte_ethdev.h
@@ -1582,6 +1582,13 @@ struct rte_eth_dev_info {
};
/**
+ * RX/TX queue states
+ */
+#define RTE_ETH_QUEUE_STATE_STOPPED 0
+#define RTE_ETH_QUEUE_STATE_STARTED 1
+#define RTE_ETH_QUEUE_STATE_HAIRPIN 2
+
+/**
* Ethernet device RX queue information structure.
* Used to retrieve information about configured queue.
*/
@@ -1591,6 +1598,8 @@ struct rte_eth_rxq_info {
uint8_t scattered_rx; /**< scattered packets RX supported. */
uint16_t nb_desc; /**< configured number of RXDs. */
uint16_t rx_buf_size; /**< hardware receive buffer size. */
+ /**< Queues state: STARTED(1) / STOPPED(0). */
+ uint8_t queue_state;
} __rte_cache_min_aligned;
/**
@@ -1600,6 +1609,8 @@ struct rte_eth_rxq_info {
struct rte_eth_txq_info {
struct rte_eth_txconf conf; /**< queue config parameters. */
uint16_t nb_desc; /**< configured number of TXDs. */
+ /**< Queues state: STARTED(1) / STOPPED(0). */
+ uint8_t queue_state;
} __rte_cache_min_aligned;
/* Generic Burst mode flag definition, values can be ORed. */
--
2.7.4
[dpdk-dev] [PATCH v2] ip_frag: fix fragmenting ipv4 packet with header option
From: Pu Xu <583493...@qq.com>
When fragmenting ipv4 packet, the data offset should be calculated through
the ihl field in ip header rather than using sizeof(struct rte_ipv4_hdr).
Fixes: 4c38e5532a07 ("ip_frag: refactor IPv4 fragmentation into a proper
library")
Signed-off-by: Pu Xu <583493...@qq.com>
---
lib/librte_ip_frag/rte_ipv4_fragmentation.c | 34 +
1 file changed, 21 insertions(+), 13 deletions(-)
diff --git a/lib/librte_ip_frag/rte_ipv4_fragmentation.c
b/lib/librte_ip_frag/rte_ipv4_fragmentation.c
index e9de335ae..2e7739d02 100644
--- a/lib/librte_ip_frag/rte_ipv4_fragmentation.c
+++ b/lib/librte_ip_frag/rte_ipv4_fragmentation.c
@@ -23,10 +23,10 @@
#defineIPV4_HDR_FO_ALIGN (1 <<
RTE_IPV4_HDR_FO_SHIFT)
static inline void __fill_ipv4hdr_frag(struct rte_ipv4_hdr *dst,
- const struct rte_ipv4_hdr *src, uint16_t len, uint16_t fofs,
- uint16_t dofs, uint32_t mf)
+ const struct rte_ipv4_hdr *src, uint16_t header_len,
+ uint16_t len, uint16_t fofs, uint16_t dofs, uint32_t mf)
{
- rte_memcpy(dst, src, sizeof(*dst));
+ rte_memcpy(dst, src, header_len);
fofs = (uint16_t)(fofs + (dofs >> RTE_IPV4_HDR_FO_SHIFT));
fofs = (uint16_t)(fofs | mf << RTE_IPV4_HDR_MF_SHIFT);
dst->fragment_offset = rte_cpu_to_be_16(fofs);
@@ -74,7 +74,7 @@ rte_ipv4_fragment_packet(struct rte_mbuf *pkt_in,
struct rte_ipv4_hdr *in_hdr;
uint32_t out_pkt_pos, in_seg_data_pos;
uint32_t more_in_segs;
- uint16_t fragment_offset, flag_offset, frag_size;
+ uint16_t fragment_offset, flag_offset, frag_size, header_len;
uint16_t frag_bytes_remaining;
/*
@@ -86,14 +86,22 @@ rte_ipv4_fragment_packet(struct rte_mbuf *pkt_in,
unlikely(mtu_size < RTE_ETHER_MIN_MTU))
return -EINVAL;
+ in_hdr = rte_pktmbuf_mtod(pkt_in, struct rte_ipv4_hdr *);
+ header_len = (in_hdr->version_ihl & RTE_IPV4_HDR_IHL_MASK) *
+ RTE_IPV4_IHL_MULTIPLIER;
+
+ /* Check IP header length */
+ if (unlikely(pkt_in->data_len < header_len) ||
+ unlikely(mtu_size < header_len))
+ return -EINVAL;
+
/*
* Ensure the IP payload length of all fragments is aligned to a
* multiple of 8 bytes as per RFC791 section 2.3.
*/
- frag_size = RTE_ALIGN_FLOOR((mtu_size - sizeof(struct rte_ipv4_hdr)),
+ frag_size = RTE_ALIGN_FLOOR((mtu_size - header_len),
IPV4_HDR_FO_ALIGN);
- in_hdr = rte_pktmbuf_mtod(pkt_in, struct rte_ipv4_hdr *);
flag_offset = rte_cpu_to_be_16(in_hdr->fragment_offset);
/* If Don't Fragment flag is set */
@@ -102,11 +110,11 @@ rte_ipv4_fragment_packet(struct rte_mbuf *pkt_in,
/* Check that pkts_out is big enough to hold all fragments */
if (unlikely(frag_size * nb_pkts_out <
- (uint16_t)(pkt_in->pkt_len - sizeof(struct rte_ipv4_hdr
+ (uint16_t)(pkt_in->pkt_len - header_len)))
return -EINVAL;
in_seg = pkt_in;
- in_seg_data_pos = sizeof(struct rte_ipv4_hdr);
+ in_seg_data_pos = header_len;
out_pkt_pos = 0;
fragment_offset = 0;
@@ -124,8 +132,8 @@ rte_ipv4_fragment_packet(struct rte_mbuf *pkt_in,
}
/* Reserve space for the IP header that will be built later */
- out_pkt->data_len = sizeof(struct rte_ipv4_hdr);
- out_pkt->pkt_len = sizeof(struct rte_ipv4_hdr);
+ out_pkt->data_len = header_len;
+ out_pkt->pkt_len = header_len;
frag_bytes_remaining = frag_size;
out_seg_prev = out_pkt;
@@ -176,14 +184,14 @@ rte_ipv4_fragment_packet(struct rte_mbuf *pkt_in,
out_hdr = rte_pktmbuf_mtod(out_pkt, struct rte_ipv4_hdr *);
- __fill_ipv4hdr_frag(out_hdr, in_hdr,
+ __fill_ipv4hdr_frag(out_hdr, in_hdr, header_len,
(uint16_t)out_pkt->pkt_len,
flag_offset, fragment_offset, more_in_segs);
fragment_offset = (uint16_t)(fragment_offset +
- out_pkt->pkt_len - sizeof(struct rte_ipv4_hdr));
+ out_pkt->pkt_len - header_len);
- out_pkt->l3_len = sizeof(struct rte_ipv4_hdr);
+ out_pkt->l3_len = header_len;
/* Write the fragment to the output list */
pkts_out[out_pkt_pos] = out_pkt;
--
2.17.0
[dpdk-dev] [PATCH v2] eal: fix race in ctrl thread creation
As reported by Luc, there is a race where the barrier is destroyed by
one thread, while the other thread did not yet leave
pthread_barrier_wait.
This patch fixes the race condition by adding an atomic counter to
ensure that the barrier is destroyed only it is not used by any thread.
Fixes: 3a0d465d4c53 ("eal: fix use-after-free on control thread creation")
Cc: jianfeng@intel.com
Cc: sta...@dpdk.org
Reported-by: Luc Pelletier
Signed-off-by: David Marchand
Signed-off-by: Olivier Matz
---
Hi Luc,
Thank you for reporting this problem and submitting the patch.
I think the issue can be fixed without any loop, like in this
patch. What do you think?
Regards,
Olivier
lib/librte_eal/common/eal_common_thread.c | 38 +--
1 file changed, 21 insertions(+), 17 deletions(-)
diff --git a/lib/librte_eal/common/eal_common_thread.c
b/lib/librte_eal/common/eal_common_thread.c
index 73a055902a..891f825e87 100644
--- a/lib/librte_eal/common/eal_common_thread.c
+++ b/lib/librte_eal/common/eal_common_thread.c
@@ -170,11 +170,11 @@ struct rte_thread_ctrl_params {
void *(*start_routine)(void *);
void *arg;
pthread_barrier_t configured;
+ unsigned int barrier_refcnt;
};
static void *ctrl_thread_init(void *arg)
{
- int ret;
struct internal_config *internal_conf =
eal_get_internal_configuration();
rte_cpuset_t *cpuset = &internal_conf->ctrl_cpuset;
@@ -184,8 +184,9 @@ static void *ctrl_thread_init(void *arg)
__rte_thread_init(rte_lcore_id(), cpuset);
- ret = pthread_barrier_wait(¶ms->configured);
- if (ret == PTHREAD_BARRIER_SERIAL_THREAD) {
+ pthread_barrier_wait(¶ms->configured);
+ if (__atomic_sub_fetch(¶ms->barrier_refcnt, 1,
+ __ATOMIC_ACQ_REL) == 0) {
pthread_barrier_destroy(¶ms->configured);
free(params);
}
@@ -210,15 +211,17 @@ rte_ctrl_thread_create(pthread_t *thread, const char
*name,
params->start_routine = start_routine;
params->arg = arg;
-
- pthread_barrier_init(¶ms->configured, NULL, 2);
-
- ret = pthread_create(thread, attr, ctrl_thread_init, (void *)params);
+ __atomic_store_n(¶ms->barrier_refcnt, 2, __ATOMIC_RELEASE);
+ ret = pthread_barrier_init(¶ms->configured, NULL, 2);
if (ret != 0) {
free(params);
return -ret;
}
+ ret = pthread_create(thread, attr, ctrl_thread_init, (void *)params);
+ if (ret != 0)
+ goto fail;
+
if (name != NULL) {
ret = rte_thread_setname(*thread, name);
if (ret < 0)
@@ -227,25 +230,26 @@ rte_ctrl_thread_create(pthread_t *thread, const char
*name,
}
ret = pthread_setaffinity_np(*thread, sizeof(*cpuset), cpuset);
- if (ret)
- goto fail;
+ if (ret != 0)
+ goto fail_cancel;
- ret = pthread_barrier_wait(¶ms->configured);
- if (ret == PTHREAD_BARRIER_SERIAL_THREAD) {
+ pthread_barrier_wait(¶ms->configured);
+ if (__atomic_sub_fetch(¶ms->barrier_refcnt, 1,
+ __ATOMIC_ACQ_REL) == 0) {
pthread_barrier_destroy(¶ms->configured);
free(params);
}
return 0;
-fail:
- if (PTHREAD_BARRIER_SERIAL_THREAD ==
- pthread_barrier_wait(¶ms->configured)) {
- pthread_barrier_destroy(¶ms->configured);
- free(params);
- }
+fail_cancel:
pthread_cancel(*thread);
pthread_join(*thread, NULL);
+
+fail:
+ pthread_barrier_destroy(¶ms->configured);
+ free(params);
+
return -ret;
}
--
2.29.2
Re: [dpdk-dev] [PATCH v5 5/8] eventdev: add Tx adapter event vector support
> -Original Message-
> From: pbhagavat...@marvell.com
> Sent: Wednesday, March 24, 2021 10:35 AM
> To: jer...@marvell.com; Jayatheerthan, Jay ;
> Carrillo, Erik G ; Gujjar,
> Abhinandan S ; McDaniel, Timothy
> ; hemant.agra...@nxp.com; Van
> Haaren, Harry ; mattias.ronnblom
> ; Ma, Liang J
>
> Cc: dev@dpdk.org; Pavan Nikhilesh
> Subject: [dpdk-dev] [PATCH v5 5/8] eventdev: add Tx adapter event vector
> support
>
> From: Pavan Nikhilesh
>
> Add event vector support for event eth Tx adapter, the implementation
> receives events from the single linked queue and based on
> rte_event_vector::union_valid transmits the vector of mbufs to a given
Typo: attr_valid instead of union_valid
> port, queue pair.
>
> Signed-off-by: Pavan Nikhilesh
> ---
> .../rte_event_eth_tx_adapter.c| 66 ---
> lib/librte_eventdev/rte_eventdev.c| 5 +-
> 2 files changed, 60 insertions(+), 11 deletions(-)
>
> diff --git a/lib/librte_eventdev/rte_event_eth_tx_adapter.c
> b/lib/librte_eventdev/rte_event_eth_tx_adapter.c
> index 5b4c42dcf..db260bfb6 100644
> --- a/lib/librte_eventdev/rte_event_eth_tx_adapter.c
> +++ b/lib/librte_eventdev/rte_event_eth_tx_adapter.c
> @@ -510,6 +510,47 @@ txa_service_buffer_retry(struct rte_mbuf **pkts,
> uint16_t unsent,
> stats->tx_dropped += unsent - sent;
> }
>
> +static uint16_t
> +txa_process_event_vector(struct txa_service_data *txa,
> + struct rte_event_vector *vec)
> +{
> + struct txa_service_queue_info *tqi;
> + uint16_t port, queue, nb_tx = 0;
> + struct rte_mbuf **mbufs;
> + int i;
> +
> + mbufs = (struct rte_mbuf **)vec->mbufs;
> + if (vec->attr_valid) {
> + port = vec->port;
> + queue = vec->queue;
> + tqi = txa_service_queue(txa, port, queue);
> + if (unlikely(tqi == NULL || !tqi->added)) {
> + rte_pktmbuf_free_bulk(mbufs, vec->nb_elem);
> + rte_mempool_put(rte_mempool_from_obj(vec), vec);
> + return 0;
> + }
> + for (i = 0; i < vec->nb_elem; i++) {
> + nb_tx += rte_eth_tx_buffer(port, queue, tqi->tx_buf,
> +mbufs[i]);
> + }
> + } else {
> + for (i = 0; i < vec->nb_elem; i++) {
> + port = mbufs[i]->port;
> + queue = rte_event_eth_tx_adapter_txq_get(mbufs[i]);
> + tqi = txa_service_queue(txa, port, queue);
> + if (unlikely(tqi == NULL || !tqi->added)) {
> + rte_pktmbuf_free(mbufs[i]);
> + continue;
> + }
> + nb_tx += rte_eth_tx_buffer(port, queue, tqi->tx_buf,
> +mbufs[i]);
> + }
> + }
> + rte_mempool_put(rte_mempool_from_obj(vec), vec);
> +
> + return nb_tx;
> +}
> +
> static void
> txa_service_tx(struct txa_service_data *txa, struct rte_event *ev,
> uint32_t n)
> @@ -522,22 +563,27 @@ txa_service_tx(struct txa_service_data *txa, struct
> rte_event *ev,
>
> nb_tx = 0;
> for (i = 0; i < n; i++) {
> - struct rte_mbuf *m;
> uint16_t port;
> uint16_t queue;
> struct txa_service_queue_info *tqi;
>
> - m = ev[i].mbuf;
> - port = m->port;
> - queue = rte_event_eth_tx_adapter_txq_get(m);
> + if (!(ev[i].event_type & RTE_EVENT_TYPE_VECTOR)) {
> + struct rte_mbuf *m;
>
> - tqi = txa_service_queue(txa, port, queue);
> - if (unlikely(tqi == NULL || !tqi->added)) {
> - rte_pktmbuf_free(m);
> - continue;
> - }
> + m = ev[i].mbuf;
> + port = m->port;
> + queue = rte_event_eth_tx_adapter_txq_get(m);
>
> - nb_tx += rte_eth_tx_buffer(port, queue, tqi->tx_buf, m);
> + tqi = txa_service_queue(txa, port, queue);
> + if (unlikely(tqi == NULL || !tqi->added)) {
> + rte_pktmbuf_free(m);
> + continue;
> + }
> +
> + nb_tx += rte_eth_tx_buffer(port, queue, tqi->tx_buf, m);
> + } else {
> + nb_tx += txa_process_event_vector(txa, ev[i].vec);
> + }
> }
>
> stats->tx_packets += nb_tx;
> diff --git a/lib/librte_eventdev/rte_eventdev.c
> b/lib/librte_eventdev/rte_eventdev.c
> index 254a31b1f..ed6b5ba59 100644
> --- a/lib/librte_eventdev/rte_eventdev.c
> +++ b/lib/librte_eventdev/rte_eventdev.c
> @@ -196,7 +196,10 @@ rte_event_eth_tx_adapter_caps_get(uint8_t dev_id,
> uint16_t eth_port_id,
> if (caps == NULL)
> return -EINVAL;
>
> - *
[dpdk-dev] [PATCH] maintainers: update for telemetry
Replace Kevin Laatz with Ciara Power. Signed-off-by: Ciara Power --- MAINTAINERS | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/MAINTAINERS b/MAINTAINERS index 0f5e745cd0..0ec5588540 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -1527,7 +1527,7 @@ F: lib/librte_latencystats/ F: app/test/test_latencystats.c Telemetry - EXPERIMENTAL -M: Kevin Laatz +M: Ciara Power F: lib/librte_telemetry/ F: app/test/test_telemetry* F: usertools/dpdk-telemetry* -- 2.25.1
Re: [dpdk-dev] [PATCH] net/mlx5: add Rx checksum offload flag return bad
Hi, Jiawei > -Original Message- > From: Jiawei Zhu <17826875...@163.com> > Sent: Wednesday, March 24, 2021 18:22 > To: Slava Ovsiienko ; dev@dpdk.org > Cc: zhujiawe...@huawei.com; Matan Azrad ; Shahaf > Shuler > Subject: Re: [PATCH] net/mlx5: add Rx checksum offload flag return bad > > Hi，Slava > > Thanks for your explain，the multiplications and divisions are in the > TRANSPOSE，not in the rte_be_to_cpu_16. [SO] Yes, TRANSPOSE is the macro with mul and div operators. But, these ones are translated by compiler to the simple shifts (due to operands are power of 2). The only place where TRANSPOSE is used is the rxq_cq_to_ol_flags() routine. I've compiled this one and provided the assembly listing - please see one in my previous reply. It illustrates how TRASPOSE was compiled to and presents the x86 code - we see only shifts: 43 0047 48C1EA02 shrq $2,%rdx 44 004b 48C1E802 shrq $2,%rax No any mul/div, exactly as we expected. > So I think use if-else directly could improves the performance. [SO] The if/else construction is usually compiled to conditional jumps, the branch prediction in CPU over the various ingress traffic patterns (we are analyzing the flags of the received packets) might not work well and we’ll get performance penalty. Hence, it seems the best practice is not to have the conditional jumps at all. The existing code follows this approach as we can see from the assembly listing - there is no conditional jumps. With best regards, Slava PS. Just removed embarrassing details from the listing - this is merely the resulting code of rxq_cq_to_ol_flags(). I removed static and made this one non-inline to see the isolated piece of code: rxq_cq_to_ol_flags: movzwl 28(%rdi),%edx // endianness conversion optimized out at all movl %edx,%eax andw $512,%dx andw $1024,%ax movzwl %dx,%edx movzwl %ax,%eax shrq $2,%rdx shrq $2,%rax orl %edx,%eax ret PPS. As we can see - the shift values are the same for both flags, so there might be some area to optimize (we could have only one shift and only one masking with AND)
Re: [dpdk-dev] [PATCH v4 0/4] add new kv hash table
Hi Thomas, On 25/03/2021 00:28, Thomas Monjalon wrote: 08/05/2020 21:58, Vladimir Medvedkin: Currently DPDK has a special implementation of a hash table for 4 byte keys which is called FBK hash. Unfortunately its main drawback is that it only supports 2 byte values. The new implementation called KV hash supports 4 byte keys and 8 byte associated values, which is enough to store a pointer. Waiting for a v5. Is it abandoned? It is suspended till further rework. -- Regards, Vladimir
Re: [dpdk-dev] [dpdk-dev v21.11] [PATCH v5 8/8] eventdev: simplify Rx adapter event vector config
> -Original Message-
> From: pbhagavat...@marvell.com
> Sent: Wednesday, March 24, 2021 10:35 AM
> To: jer...@marvell.com; Jayatheerthan, Jay ;
> Carrillo, Erik G ; Gujjar,
> Abhinandan S ; McDaniel, Timothy
> ; hemant.agra...@nxp.com; Van
> Haaren, Harry ; mattias.ronnblom
> ; Ma, Liang J
> ; Ray Kinsella ; Neil Horman
>
> Cc: dev@dpdk.org; Pavan Nikhilesh
> Subject: [dpdk-dev v21.11] [PATCH v5 8/8] eventdev: simplify Rx adapter event
> vector config
>
> From: Pavan Nikhilesh
>
> Include vector configuration into the structure
> ``rte_event_eth_rx_adapter_queue_conf`` used when configuring rest
> of the Rx adapter ethernet device Rx queue parameters.
> This simplifies event vector configuration as it avoids splitting
> configuration per Rx queue.
>
> Signed-off-by: Pavan Nikhilesh
> ---
> app/test-eventdev/test_pipeline_common.c | 16 +-
> lib/librte_eventdev/eventdev_pmd.h| 29 ---
> .../rte_event_eth_rx_adapter.c| 168 ++
> .../rte_event_eth_rx_adapter.h| 27 ---
> lib/librte_eventdev/version.map | 1 -
> 5 files changed, 57 insertions(+), 184 deletions(-)
>
> diff --git a/app/test-eventdev/test_pipeline_common.c
> b/app/test-eventdev/test_pipeline_common.c
> index d5ef90500..76aee254b 100644
> --- a/app/test-eventdev/test_pipeline_common.c
> +++ b/app/test-eventdev/test_pipeline_common.c
> @@ -331,7 +331,6 @@ pipeline_event_rx_adapter_setup(struct evt_options *opt,
> uint8_t stride,
> uint16_t prod;
> struct rte_mempool *vector_pool = NULL;
> struct rte_event_eth_rx_adapter_queue_conf queue_conf;
> - struct rte_event_eth_rx_adapter_event_vector_config vec_conf;
>
> memset(&queue_conf, 0,
> sizeof(struct rte_event_eth_rx_adapter_queue_conf));
> @@ -397,8 +396,12 @@ pipeline_event_rx_adapter_setup(struct evt_options *opt,
> uint8_t stride,
> }
>
> if (cap & RTE_EVENT_ETH_RX_ADAPTER_CAP_EVENT_VECTOR) {
> + queue_conf.vector_sz = opt->vector_size;
> + queue_conf.vector_timeout_ns =
> + opt->vector_tmo_nsec;
> queue_conf.rx_queue_flags |=
> RTE_EVENT_ETH_RX_ADAPTER_QUEUE_EVENT_VECTOR;
> + queue_conf.vector_mp = vector_pool;
> } else {
> evt_err("Rx adapter doesn't support event
> vector");
> return -EINVAL;
> @@ -418,17 +421,6 @@ pipeline_event_rx_adapter_setup(struct evt_options *opt,
> uint8_t stride,
> return ret;
> }
>
> - if (opt->ena_vector) {
> - vec_conf.vector_sz = opt->vector_size;
> - vec_conf.vector_timeout_ns = opt->vector_tmo_nsec;
> - vec_conf.vector_mp = vector_pool;
> - if (rte_event_eth_rx_adapter_queue_event_vector_config(
> - prod, prod, -1, &vec_conf) < 0) {
> - evt_err("Failed to configure event
> vectorization for Rx adapter");
> - return -EINVAL;
> - }
> - }
> -
> if (!(cap & RTE_EVENT_ETH_RX_ADAPTER_CAP_INTERNAL_PORT)) {
> uint32_t service_id = -1U;
>
> diff --git a/lib/librte_eventdev/eventdev_pmd.h
> b/lib/librte_eventdev/eventdev_pmd.h
> index 0f724ac85..63b3bc4b5 100644
> --- a/lib/librte_eventdev/eventdev_pmd.h
> +++ b/lib/librte_eventdev/eventdev_pmd.h
> @@ -667,32 +667,6 @@ typedef int
> (*eventdev_eth_rx_adapter_vector_limits_get_t)(
> const struct rte_eventdev *dev, const struct rte_eth_dev *eth_dev,
> struct rte_event_eth_rx_adapter_vector_limits *limits);
>
> -struct rte_event_eth_rx_adapter_event_vector_config;
> -/**
> - * Enable event vector on an given Rx queue of a ethernet devices belonging
> to
> - * the Rx adapter.
> - *
> - * @param dev
> - * Event device pointer
> - *
> - * @param eth_dev
> - * Ethernet device pointer
> - *
> - * @param rx_queue_id
> - * The Rx queue identifier
> - *
> - * @param config
> - * Pointer to the event vector configuration structure.
> - *
> - * @return
> - * - 0: Success.
> - * - <0: Error code returned by the driver function.
> - */
> -typedef int (*eventdev_eth_rx_adapter_event_vector_config_t)(
> - const struct rte_eventdev *dev, const struct rte_eth_dev *eth_dev,
> - int32_t rx_queue_id,
> - const struct rte_event_eth_rx_adapter_event_vector_config *config);
> -
> typedef uint32_t rte_event_pmd_selftest_seqn_t;
> extern int rte_event_pmd_selftest_seqn_dynfield_offset;
>
> @@ -1118,9 +1092,6 @@ struct rte_eventdev_ops {
> eventdev_eth_rx_adapter_vector_limits_get_t
> eth_rx_adapter_vector_limits_get;
> /**< Get event vec
[dpdk-dev] [PATCH] net/ice: refine RSS configure
The ICE_RSS_ANY_HEADERS will try to enable outer RSS for
non-tunnel case and inner RSS for tunnel case. This confuse
user.
As we already have ICE_RSS_INNER_HEADER for tunnel case,
So, replace ICE_RSS_ANY_HEADERS with ICE_RSS_OUTER_HEADERS
for all exist flow which only specified the outer pattern.
To enable inner RSS for any tunnel cases, a separated rule
should be enabled.
The patch also remove some unncessary condition check for GTPU
in base code, as we already can support outer RSS for GTPU.
Signed-off-by: Qi Zhang
---
drivers/net/ice/base/ice_flow.c | 14
drivers/net/ice/ice_ethdev.c| 4 ++--
drivers/net/ice/ice_hash.c | 38 -
3 files changed, 21 insertions(+), 35 deletions(-)
diff --git a/drivers/net/ice/base/ice_flow.c b/drivers/net/ice/base/ice_flow.c
index d123206fc6..bceb257d61 100644
--- a/drivers/net/ice/base/ice_flow.c
+++ b/drivers/net/ice/base/ice_flow.c
@@ -3678,13 +3678,6 @@ ice_add_rss_cfg_sync(struct ice_hw *hw, u16 vsi_handle,
if (status)
goto exit;
- /* Don't do RSS for GTPU Outer */
- if (segs_cnt == ICE_FLOW_SEG_SINGLE &&
- segs[segs_cnt - 1].hdrs & ICE_FLOW_SEG_HDR_GTPU) {
- status = ICE_SUCCESS;
- goto exit;
- }
-
/* Search for a flow profile that has matching headers, hash fields
* and has the input VSI associated to it. If found, no further
* operations required and exit.
@@ -3847,13 +3840,6 @@ ice_rem_rss_cfg_sync(struct ice_hw *hw, u16 vsi_handle,
if (status)
goto out;
- /* Don't do RSS for GTPU Outer */
- if (segs_cnt == ICE_FLOW_SEG_SINGLE &&
- segs[segs_cnt - 1].hdrs & ICE_FLOW_SEG_HDR_GTPU) {
- status = ICE_SUCCESS;
- goto out;
- }
-
prof = ice_flow_find_prof_conds(hw, blk, ICE_FLOW_RX, segs, segs_cnt,
vsi_handle,
ICE_FLOW_FIND_PROF_CHK_FLDS);
diff --git a/drivers/net/ice/ice_ethdev.c b/drivers/net/ice/ice_ethdev.c
index 3e85e5f629..4ccf31cb41 100644
--- a/drivers/net/ice/ice_ethdev.c
+++ b/drivers/net/ice/ice_ethdev.c
@@ -2348,7 +2348,7 @@ hash_cfg_reset(struct ice_rss_hash_cfg *cfg)
cfg->hash_flds = 0;
cfg->addl_hdrs = 0;
cfg->symm = 0;
- cfg->hdr_type = ICE_RSS_ANY_HEADERS;
+ cfg->hdr_type = ICE_RSS_OUTER_HEADERS;
}
static int
@@ -2833,7 +2833,7 @@ ice_rss_hash_set(struct ice_pf *pf, uint64_t rss_hf)
__func__, ret);
cfg.symm = 0;
- cfg.hdr_type = ICE_RSS_ANY_HEADERS;
+ cfg.hdr_type = ICE_RSS_OUTER_HEADERS;
/* Configure RSS for IPv4 with src/dst addr as input set */
if (rss_hf & ETH_RSS_IPV4) {
cfg.addl_hdrs = ICE_FLOW_SEG_HDR_IPV4 |
ICE_FLOW_SEG_HDR_IPV_OTHER;
diff --git a/drivers/net/ice/ice_hash.c b/drivers/net/ice/ice_hash.c
index 58a0c18d09..7d7e7052da 100644
--- a/drivers/net/ice/ice_hash.c
+++ b/drivers/net/ice/ice_hash.c
@@ -110,7 +110,7 @@ struct ice_rss_hash_cfg ipv4_tmplt = {
ICE_FLOW_SEG_HDR_ETH | ICE_FLOW_SEG_HDR_IPV4 |
ICE_FLOW_SEG_HDR_IPV_OTHER,
ICE_FLOW_HASH_ETH | ICE_FLOW_HASH_IPV4,
- ICE_RSS_ANY_HEADERS,
+ ICE_RSS_OUTER_HEADERS,
0
};
@@ -118,7 +118,7 @@ struct ice_rss_hash_cfg ipv4_udp_tmplt = {
ICE_FLOW_SEG_HDR_ETH | ICE_FLOW_SEG_HDR_IPV4 |
ICE_FLOW_SEG_HDR_IPV_OTHER | ICE_FLOW_SEG_HDR_UDP,
ICE_FLOW_HASH_ETH | ICE_HASH_UDP_IPV4 | ICE_IPV4_PROT,
- ICE_RSS_ANY_HEADERS,
+ ICE_RSS_OUTER_HEADERS,
0
};
@@ -126,7 +126,7 @@ struct ice_rss_hash_cfg ipv4_tcp_tmplt = {
ICE_FLOW_SEG_HDR_ETH | ICE_FLOW_SEG_HDR_IPV4 |
ICE_FLOW_SEG_HDR_IPV_OTHER | ICE_FLOW_SEG_HDR_TCP,
ICE_FLOW_HASH_ETH | ICE_HASH_TCP_IPV4 | ICE_IPV4_PROT,
- ICE_RSS_ANY_HEADERS,
+ ICE_RSS_OUTER_HEADERS,
0
};
@@ -134,7 +134,7 @@ struct ice_rss_hash_cfg ipv4_sctp_tmplt = {
ICE_FLOW_SEG_HDR_ETH | ICE_FLOW_SEG_HDR_IPV4 |
ICE_FLOW_SEG_HDR_IPV_OTHER | ICE_FLOW_SEG_HDR_SCTP,
ICE_FLOW_HASH_ETH | ICE_HASH_SCTP_IPV4 | ICE_IPV4_PROT,
- ICE_RSS_ANY_HEADERS,
+ ICE_RSS_OUTER_HEADERS,
0
};
@@ -142,7 +142,7 @@ struct ice_rss_hash_cfg ipv6_tmplt = {
ICE_FLOW_SEG_HDR_ETH | ICE_FLOW_SEG_HDR_IPV6 |
ICE_FLOW_SEG_HDR_IPV_OTHER,
ICE_FLOW_HASH_ETH | ICE_FLOW_HASH_IPV6,
- ICE_RSS_ANY_HEADERS,
+ ICE_RSS_OUTER_HEADERS,
0
};
@@ -150,7 +150,7 @@ struct ice_rss_hash_cfg ipv6_udp_tmplt = {
ICE_FLOW_SEG_HDR_ETH | ICE_FLOW_SEG_HDR_IPV6 |
ICE_FLOW_SEG_HDR_IPV_OTHER | ICE_FLOW_SEG_HDR_UDP,
ICE_FLOW_HASH_ETH | ICE_HASH_UDP_IPV6 | ICE_IPV6_PROT,
- ICE_RSS_ANY_HEADERS,
+ ICE_RSS_OUTER_HEADERS,
0
};
@@ -158,7 +158,7 @@ struct ice_rss_hash_cfg ipv6_tcp_tmplt = {
ICE_FLOW_SEG_HDR_ETH | ICE_FLOW_SEG_HDR_IP
Re: [dpdk-dev] [PATCH 1/7] common/octeontx: enable build only on 64bit Linux
On Thu, Mar 25, 2021 at 4:33 PM Thomas Monjalon wrote: > > 25/03/2021 11:58, Kinsella, Ray: > > On 25/03/2021 10:46, Thomas Monjalon wrote: > > > 25/03/2021 11:42, Thomas Monjalon: > > >> 24/03/2021 11:55, Jerin Jacob: > > >>> On Thu, Feb 25, 2021 at 10:33 PM wrote: > > > > From: Pavan Nikhilesh > > > > Due to Linux kernel dependency, only enable build for 64bit Linux. > > > > Signed-off-by: Pavan Nikhilesh > > >>> > > >>> Series Acked-by: Jerin Jacob > > >> > > >> I've reorganized the commits per family of drivers, > > >> so it makes more sense than grouping per driver class > > >> with "common/octeontx" for title for all: > > >> > > >> net/thunderx: enable build only on 64-bit Linux > > >> common/octeontx: enable build only on 64-bit Linux > > >> common/octeontx2: enable build only on 64-bit Linux > > >> > > >> and applied. > > > > > > Actually not applied yet. > > > I'm not sure what to do for the ABI check which is broken > > > because some drivers are not compiled anymore in 32-bit build. > > > I've workarounded locally by removing the dump files in the reference > > > build. > > > Should we add an exception in libabigail.abignore? > > > > > In the past we said that depreciating HW support would be considered to be > > same as an ABI Breakage. > > > > From the policy ... > > "Updates to the minimum hardware requirements, which drop support for > > hardware which was previously supported, should be treated as an ABI > > change." > > So the patches should wait 21.11. > Everybody agree? Looks good to me to postpone. @Ray Kinsella @Thomas Monjalon @McDaniel, Timothy @David Marchand @Neil Horman Currently, I merged DLB v1 driver removal patch to next-eventdev. Is this ABI breakge[1]? http://patches.dpdk.org/project/dpdk/patch/20210316210812.15614-1-timothy.mcdan...@intel.com/ [1] >From the policy ... "Updates to the minimum hardware requirements, which drop support for hardware which was previously supported, should be treated as an ABI change."
Re: [dpdk-dev] [PATCH 1/7] common/octeontx: enable build only on 64bit Linux
On 25/03/2021 12:46, Jerin Jacob wrote: > On Thu, Mar 25, 2021 at 4:33 PM Thomas Monjalon wrote: >> >> 25/03/2021 11:58, Kinsella, Ray: >>> On 25/03/2021 10:46, Thomas Monjalon wrote: 25/03/2021 11:42, Thomas Monjalon: > 24/03/2021 11:55, Jerin Jacob: >> On Thu, Feb 25, 2021 at 10:33 PM wrote: >>> >>> From: Pavan Nikhilesh >>> >>> Due to Linux kernel dependency, only enable build for 64bit Linux. >>> >>> Signed-off-by: Pavan Nikhilesh >> >> Series Acked-by: Jerin Jacob > > I've reorganized the commits per family of drivers, > so it makes more sense than grouping per driver class > with "common/octeontx" for title for all: > > net/thunderx: enable build only on 64-bit Linux > common/octeontx: enable build only on 64-bit Linux > common/octeontx2: enable build only on 64-bit Linux > > and applied. Actually not applied yet. I'm not sure what to do for the ABI check which is broken because some drivers are not compiled anymore in 32-bit build. I've workarounded locally by removing the dump files in the reference build. Should we add an exception in libabigail.abignore? >>> In the past we said that depreciating HW support would be considered to be >>> same as an ABI Breakage. >>> >>> From the policy ... >>> "Updates to the minimum hardware requirements, which drop support for >>> hardware which was previously supported, should be treated as an ABI >>> change." >> >> So the patches should wait 21.11. >> Everybody agree? > > Looks good to me to postpone. > > @Ray Kinsella @Thomas Monjalon @McDaniel, Timothy @David Marchand @Neil > Horman > > Currently, I merged DLB v1 driver removal patch to next-eventdev. Is > this ABI breakge[1]? > > http://patches.dpdk.org/project/dpdk/patch/20210316210812.15614-1-timothy.mcdan...@intel.com/ > > [1] > From the policy ... > "Updates to the minimum hardware requirements, which drop support for > hardware which was previously supported, should be treated as an ABI > change." +1
[dpdk-dev] [Bug 667] Fail to compile debug mode with GCC 5.4.0
https://bugs.dpdk.org/show_bug.cgi?id=667 Bug ID: 667 Summary: Fail to compile debug mode with GCC 5.4.0 Product: DPDK Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: Normal Component: meson Assignee: dev@dpdk.org Reporter: wis...@mellanox.com Target Milestone: --- How to reproduce: meson build -Ddisable_drivers=net/mlx4 —buildtype=debug; ninja -C build/ Results: -c ../drivers/net/iavf/iavf_rxtx_vec_avx512.c ../drivers/net/iavf/iavf_rxtx_vec_avx512.c: In function ‘_iavf_recv_raw_pkts_vec_avx512’: ../drivers/net/iavf/iavf_rxtx_vec_avx512.c:615:1: error: unrecognizable insn: } ^ (insn 888 887 889 36 (set (mem/c:V4DI (plus:DI (reg/f:DI 82 virtual-stack-vars) (const_int -5120 [0xec00])) [0 ptypes6_7+0 S32 A256]) (vec_merge:V4DI (vec_select:V4DI (reg:V8DI 999) (parallel [ (const_int 4 [0×4]) (const_int 5 [0×5]) (const_int 6 [0×6]) (const_int 7 [0×7]) ])) (reg:V4DI 188 [ D.49785 ]) (reg:QI 1000))) ../drivers/net/iavf/iavf_rxtx_vec_avx512.c:389 -1 (nil)) ../drivers/net/iavf/iavf_rxtx_vec_avx512.c:615:1: internal compiler error: in extract_insn, at recog.c:2343 Please submit a full bug report, with preprocessed source if appropriate. See for instructions. [40/1286] Compiling C object drivers/net/i40e/libi40e_avx512_lib.a.p/i40e_rxtx_vec_avx512.c.o FAILED: drivers/net/i40e/libi40e_avx512_lib.a.p/i40e_rxtx_vec_avx512.c.o ccache cc -Idrivers/net/i40e/libi40e_avx512_lib.a.p -Idrivers/net/i40e -I../drivers/net/i40e -Idrivers/net/i40e/base -I../drivers/net/i40e/base -Ilib/librte_ethdev -I../lib/librte_ethdev -I. -I.. -Iconfig -I../config -Ilib/librte_eal/include -I../lib/librte_eal/include -Ilib/librte_eal/linux/include -I../lib/librte_eal/linux/include -Ilib/librte_eal/x86/include -I../lib/librte_eal/x86/include -Ilib/librte_eal/common -I../lib/librte_eal/common -Ilib/librte_eal -I../lib/librte_eal -Ilib/librte_kvargs -I../lib/librte_kvargs -Ilib/librte_metrics -I../lib/librte_metrics -Ilib/librte_telemetry -I../lib/librte_telemetry -Ilib/librte_net -I../lib/librte_net -Ilib/librte_mbuf -I../lib/librte_mbuf -Ilib/librte_mempool -I../lib/librte_mempool -Ilib/librte_ring -I../lib/librte_ring -Ilib/librte_meter -I../lib/librte_meter -Ilib/librte_hash -I../lib/librte_hash -Ilib/librte_rcu -I../lib/librte_rcu -fdiagnostics-color=always -pipe -D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch -g -include rte_config.h -Wextra -Wcast-qual -Wdeprecated -Wformat -Wformat-nonliteral -Wformat-security -Wmissing-declarations -Wmissing-prototypes -Wnested-externs -Wold-style-definition -Wpointer-arith -Wsign-compare -Wstrict-prototypes -Wundef -Wwrite-strings -Wno-missing-field-initializers -D_GNU_SOURCE -fPIC -march=native -DALLOW_EXPERIMENTAL_API -DALLOW_INTERNAL_API -DPF_DRIVER -DVF_DRIVER -DINTEGRATED_VF -DX722_A0_SUPPORT -DCC_AVX2_SUPPORT -DCC_AVX512_SUPPORT -mavx512f -mavx512bw -MD -MQ drivers/net/i40e/libi40e_avx512_lib.a.p/i40e_rxtx_vec_avx512.c.o -MF drivers/net/i40e/libi40e_avx512_lib.a.p/i40e_rxtx_vec_avx512.c.o.d -o drivers/net/i40e/libi40e_avx512_lib.a.p/i40e_rxtx_vec_avx512.c.o -c ../drivers/net/i40e/i40e_rxtx_vec_avx512.c ../drivers/net/i40e/i40e_rxtx_vec_avx512.c: In function ‘i40e_recv_pkts_vec_avx512’: ../drivers/net/i40e/i40e_rxtx_vec_avx512.c:807:1: error: unrecognizable insn: } ^ (insn 888 887 889 40 (set (mem/c:V4DI (plus:DI (reg/f:DI 82 virtual-stack-vars) (const_int -5152 [0xebe0])) [0 ptypes6_7+0 S32 A256]) (vec_merge:V4DI (vec_select:V4DI (reg:V8DI 998) (parallel [ (const_int 4 [0×4]) (const_int 5 [0×5]) (const_int 6 [0×6]) (const_int 7 [0×7]) ])) (reg:V4DI 219 [ D.53777 ]) (reg:QI 999))) ../drivers/net/i40e/i40e_rxtx_vec_avx512.c:464 -1 (nil)) ../drivers/net/i40e/i40e_rxtx_vec_avx512.c:807:1: internal compiler error: in extract_insn, at recog.c:2343 Please submit a full bug report, with preprocessed source if appropriate. See for instructions. [45/1286] Compiling C object drivers/net/ice/libice_avx512_lib.a.p/ice_rxtx_vec_avx512.c.o FAILED: drivers/net/ice/libice_avx512_lib.a.p/ice_rxtx_vec_avx512.c.o ccache cc -Idrivers/net/ice/libice_avx512_lib.a.p -Idrivers/net/ice -I../drivers/net/ice -Idrivers/net/ice/base -I../drivers/net/ice/base -Idrivers/common/iavf -I../drivers/common/iavf -Ilib/librte_ethdev -I../lib/librte_ethdev -I. -I.. -Iconfig -I../config -Ilib/librte_eal/include -I../lib/librte_eal/include -Ilib/librte_eal/linux/include -I../lib/librte_eal/linux/include -Ilib/librte_eal/x86/include -I../lib/librte_eal/x86/include -Ilib/librte_eal/common -I../lib/librte_eal/common -Ilib/librte_eal -I../lib/librte_eal -Ilib/librte_kvargs -I../lib/librte_kvargs -Ilib/librte_metrics -I../lib/librte_metrics -Ilib/librte_telemetry -I../lib/librte_telemetry -Ilib/librte_net -I../lib/librte_net -Ilib/librte_mbuf -I../lib/librte_mbuf -Ilib/librte_mempool -I../lib/librte_mem
Re: [dpdk-dev] [PATCH 1/7] common/octeontx: enable build only on 64bit Linux
On Thu, Mar 25, 2021 at 6:17 PM Kinsella, Ray wrote: > > > > On 25/03/2021 12:46, Jerin Jacob wrote: > > On Thu, Mar 25, 2021 at 4:33 PM Thomas Monjalon wrote: > >> > >> 25/03/2021 11:58, Kinsella, Ray: > >>> On 25/03/2021 10:46, Thomas Monjalon wrote: > 25/03/2021 11:42, Thomas Monjalon: > > 24/03/2021 11:55, Jerin Jacob: > >> On Thu, Feb 25, 2021 at 10:33 PM wrote: > >>> > >>> From: Pavan Nikhilesh > >>> > >>> Due to Linux kernel dependency, only enable build for 64bit Linux. > >>> > >>> Signed-off-by: Pavan Nikhilesh > >> > >> Series Acked-by: Jerin Jacob > > > > I've reorganized the commits per family of drivers, > > so it makes more sense than grouping per driver class > > with "common/octeontx" for title for all: > > > > net/thunderx: enable build only on 64-bit Linux > > common/octeontx: enable build only on 64-bit Linux > > common/octeontx2: enable build only on 64-bit Linux > > > > and applied. > > Actually not applied yet. > I'm not sure what to do for the ABI check which is broken > because some drivers are not compiled anymore in 32-bit build. > I've workarounded locally by removing the dump files in the reference > build. > Should we add an exception in libabigail.abignore? > > >>> In the past we said that depreciating HW support would be considered to > >>> be same as an ABI Breakage. > >>> > >>> From the policy ... > >>> "Updates to the minimum hardware requirements, which drop support for > >>> hardware which was previously supported, should be treated as an ABI > >>> change." > >> > >> So the patches should wait 21.11. > >> Everybody agree? > > > > Looks good to me to postpone. > > > > @Ray Kinsella @Thomas Monjalon @McDaniel, Timothy @David Marchand @Neil > > Horman > > > > Currently, I merged DLB v1 driver removal patch to next-eventdev. Is > > this ABI breakge[1]? > > > > http://patches.dpdk.org/project/dpdk/patch/20210316210812.15614-1-timothy.mcdan...@intel.com/ > > > > [1] > > From the policy ... > > "Updates to the minimum hardware requirements, which drop support for > > hardware which was previously supported, should be treated as an ABI > > change." > > +1 Is +1 for not to remove the dlb driver or remove it?
Re: [dpdk-dev] [PATCH 1/7] common/octeontx: enable build only on 64bit Linux
On 25/03/2021 12:58, Jerin Jacob wrote: > On Thu, Mar 25, 2021 at 6:17 PM Kinsella, Ray wrote: >> >> >> >> On 25/03/2021 12:46, Jerin Jacob wrote: >>> On Thu, Mar 25, 2021 at 4:33 PM Thomas Monjalon wrote: 25/03/2021 11:58, Kinsella, Ray: > On 25/03/2021 10:46, Thomas Monjalon wrote: >> 25/03/2021 11:42, Thomas Monjalon: >>> 24/03/2021 11:55, Jerin Jacob: On Thu, Feb 25, 2021 at 10:33 PM wrote: > > From: Pavan Nikhilesh > > Due to Linux kernel dependency, only enable build for 64bit Linux. > > Signed-off-by: Pavan Nikhilesh Series Acked-by: Jerin Jacob >>> >>> I've reorganized the commits per family of drivers, >>> so it makes more sense than grouping per driver class >>> with "common/octeontx" for title for all: >>> >>> net/thunderx: enable build only on 64-bit Linux >>> common/octeontx: enable build only on 64-bit Linux >>> common/octeontx2: enable build only on 64-bit Linux >>> >>> and applied. >> >> Actually not applied yet. >> I'm not sure what to do for the ABI check which is broken >> because some drivers are not compiled anymore in 32-bit build. >> I've workarounded locally by removing the dump files in the reference >> build. >> Should we add an exception in libabigail.abignore? >> > In the past we said that depreciating HW support would be considered to > be same as an ABI Breakage. > > From the policy ... > "Updates to the minimum hardware requirements, which drop support for > hardware which was previously supported, should be treated as an ABI > change." So the patches should wait 21.11. Everybody agree? >>> >>> Looks good to me to postpone. >>> >>> @Ray Kinsella @Thomas Monjalon @McDaniel, Timothy @David Marchand @Neil >>> Horman >>> >>> Currently, I merged DLB v1 driver removal patch to next-eventdev. Is >>> this ABI breakge[1]? >>> >>> http://patches.dpdk.org/project/dpdk/patch/20210316210812.15614-1-timothy.mcdan...@intel.com/ >>> >>> [1] >>> From the policy ... >>> "Updates to the minimum hardware requirements, which drop support for >>> hardware which was previously supported, should be treated as an ABI >>> change." >> >> +1 > > Is +1 for not to remove the dlb driver or remove it? > You'll note the original reply pointing at the ABI Policy was from myself. So I would be in favor of retention until 21.11. Thats said... We should think about making the rules less strict for 32bit in future, from 21.11 onwards perhaps. How many OS Vendors are shipping 32bit OSs these days for example?
Re: [dpdk-dev] [PATCH v2] ip_frag: fix fragmenting ipv4 packet with header option
583493...@qq.com writes:
> From: Pu Xu <583493...@qq.com>
>
> When fragmenting ipv4 packet, the data offset should be calculated through
> the ihl field in ip header rather than using sizeof(struct rte_ipv4_hdr).
>
> Fixes: 4c38e5532a07 ("ip_frag: refactor IPv4 fragmentation into a proper
> library")
>
> Signed-off-by: Pu Xu <583493...@qq.com>
> ---
Thanks for this patch, it looks okay.
Can you please add a test case to app/test/test_ipfrag.c so that we can
catch any breakage in this area in the future?
Re: [dpdk-dev] [PATCH v5 4/8] eventdev: add Rx adapter event vector support
>-Original Message-
>From: Jayatheerthan, Jay
>Sent: Thursday, March 25, 2021 4:07 PM
>To: Pavan Nikhilesh Bhagavatula ; Jerin
>Jacob Kollanukkaran ; Carrillo, Erik G
>; Gujjar, Abhinandan S
>; McDaniel, Timothy
>; hemant.agra...@nxp.com; Van
>Haaren, Harry ; mattias.ronnblom
>; Ma, Liang J
>
>Cc: dev@dpdk.org
>Subject: [EXT] RE: [dpdk-dev] [PATCH v5 4/8] eventdev: add Rx adapter
>event vector support
>
>External Email
>
>--
>> -Original Message-
>> From: pbhagavat...@marvell.com
>> Sent: Wednesday, March 24, 2021 10:35 AM
>> To: jer...@marvell.com; Jayatheerthan, Jay
>; Carrillo, Erik G
>; Gujjar,
>> Abhinandan S ; McDaniel, Timothy
>; hemant.agra...@nxp.com; Van
>> Haaren, Harry ; mattias.ronnblom
>; Ma, Liang J
>>
>> Cc: dev@dpdk.org; Pavan Nikhilesh
>> Subject: [dpdk-dev] [PATCH v5 4/8] eventdev: add Rx adapter event
>vector support
>>
>> From: Pavan Nikhilesh
>>
>> Add event vector support for event eth Rx adapter, the
>implementation
>> creates vector flows based on port and queue identifier of the
>received
>> mbufs.
>>
>> Signed-off-by: Pavan Nikhilesh
>> ---
>> lib/librte_eventdev/eventdev_pmd.h| 7 +-
>> .../rte_event_eth_rx_adapter.c| 257 --
>> lib/librte_eventdev/rte_eventdev.c| 6 +-
>> 3 files changed, 250 insertions(+), 20 deletions(-)
>>
>> diff --git a/lib/librte_eventdev/eventdev_pmd.h
>b/lib/librte_eventdev/eventdev_pmd.h
>> index 9297f1433..0f724ac85 100644
>> --- a/lib/librte_eventdev/eventdev_pmd.h
>> +++ b/lib/librte_eventdev/eventdev_pmd.h
>> @@ -69,9 +69,10 @@ extern "C" {
>> } \
>> } while (0)
>>
>> -#define RTE_EVENT_ETH_RX_ADAPTER_SW_CAP \
>> -
> ((RTE_EVENT_ETH_RX_ADAPTER_CAP_OVERRIDE_FLOW_ID) |
>\
>> -
> (RTE_EVENT_ETH_RX_ADAPTER_CAP_MULTI_EVENTQ))
>> +#define RTE_EVENT_ETH_RX_ADAPTER_SW_CAP
>\
>> +((RTE_EVENT_ETH_RX_ADAPTER_CAP_OVERRIDE_FLOW_ID) |
>\
>> + (RTE_EVENT_ETH_RX_ADAPTER_CAP_MULTI_EVENTQ) |
>\
>> + (RTE_EVENT_ETH_RX_ADAPTER_CAP_EVENT_VECTOR))
>>
>> #define RTE_EVENT_CRYPTO_ADAPTER_SW_CAP \
>>
> RTE_EVENT_CRYPTO_ADAPTER_CAP_SESSION_PRIVATE_DATA
>> diff --git a/lib/librte_eventdev/rte_event_eth_rx_adapter.c
>b/lib/librte_eventdev/rte_event_eth_rx_adapter.c
>> index ac8ba5bf0..c71990078 100644
>> --- a/lib/librte_eventdev/rte_event_eth_rx_adapter.c
>> +++ b/lib/librte_eventdev/rte_event_eth_rx_adapter.c
>> @@ -26,6 +26,10 @@
>> #define BATCH_SIZE 32
>> #define BLOCK_CNT_THRESHOLD 10
>> #define ETH_EVENT_BUFFER_SIZE (4*BATCH_SIZE)
>> +#define MAX_VECTOR_SIZE 1024
>> +#define MIN_VECTOR_SIZE 4
>> +#define MAX_VECTOR_NS 1E9
>> +#define MIN_VECTOR_NS 1E5
>>
>> #define ETH_RX_ADAPTER_SERVICE_NAME_LEN 32
>> #define ETH_RX_ADAPTER_MEM_NAME_LEN 32
>> @@ -59,6 +63,20 @@ struct eth_rx_poll_entry {
>> uint16_t eth_rx_qid;
>> };
>>
>> +struct eth_rx_vector_data {
>> +TAILQ_ENTRY(eth_rx_vector_data) next;
>> +uint16_t port;
>> +uint16_t queue;
>> +uint16_t max_vector_count;
>> +uint64_t event;
>> +uint64_t ts;
>> +uint64_t vector_timeout_ticks;
>> +struct rte_mempool *vector_pool;
>> +struct rte_event_vector *vector_ev;
>> +} __rte_cache_aligned;
>> +
>> +TAILQ_HEAD(eth_rx_vector_data_list, eth_rx_vector_data);
>> +
>> /* Instance per adapter */
>> struct rte_eth_event_enqueue_buffer {
>> /* Count of events in this buffer */
>> @@ -92,6 +110,14 @@ struct rte_event_eth_rx_adapter {
>> uint32_t wrr_pos;
>> /* Event burst buffer */
>> struct rte_eth_event_enqueue_buffer event_enqueue_buffer;
>> +/* Vector enable flag */
>> +uint8_t ena_vector;
>> +/* Timestamp of previous vector expiry list traversal */
>> +uint64_t prev_expiry_ts;
>> +/* Minimum ticks to wait before traversing expiry list */
>> +uint64_t vector_tmo_ticks;
>> +/* vector list */
>> +struct eth_rx_vector_data_list vector_list;
>> /* Per adapter stats */
>> struct rte_event_eth_rx_adapter_stats stats;
>> /* Block count, counts up to BLOCK_CNT_THRESHOLD */
>> @@ -198,9 +224,11 @@ struct eth_device_info {
>> struct eth_rx_queue_info {
>> int queue_enabled; /* True if added */
>> int intr_enabled;
>> +uint8_t ena_vector;
>> uint16_t wt;/* Polling weight */
>> uint32_t flow_id_mask; /* Set to ~0 if app provides flow id else
>0 */
>> uint64_t event;
>> +struct eth_rx_vector_data vector_data;
>> };
>>
>> static struct rte_event_eth_rx_adapter **event_eth_rx_adapter;
>> @@ -722,6 +750,9 @@ rxa_flush_event_buffer(struct
>rte_event_eth_rx_adapter *rx_adapter)
>> &rx_adapter->event_enqueue_buffer;
>> struct rte_event_eth_rx_adapter_stats *stats = &rx_adapter-
>>stats;
>>
>> +if (!buf->count)
>> +return 0;
>> +
>> uint16_t n = rte_event_enqueue_new_burst(rx_adapter-
>>even
Re: [dpdk-dev] [PATCH v4 1/1] eal/interrupts: add synchronous wrapper around unregister
On Thu, Feb 18, 2021 at 10:28 PM Renata Saiakhova
wrote:
>
> Avoid race with unregister interrupt handler if interrupt
> source has some active callbacks at the moment, use wrapper
> around rte_intr_callback_unregister() to check for -EAGAIN
> return value and to loop until rte_intr_callback_unregister()
> succeeds.
>
> Signed-off-by: Renata Saiakhova
> Acked-by: Anatoly Burakov
> ---
> drivers/bus/pci/linux/pci_vfio.c| 2 +-
> lib/librte_eal/freebsd/eal_interrupts.c | 12
> lib/librte_eal/include/rte_interrupts.h | 25 +
> lib/librte_eal/linux/eal_interrupts.c | 12
> lib/librte_eal/version.map | 1 +
> 5 files changed, 51 insertions(+), 1 deletion(-)
Seeing the description of this function, I'd expect it to be the same
on all OS implementations.
Please, could you respin with Windows update?
[snip]
> diff --git a/lib/librte_eal/version.map b/lib/librte_eal/version.map
> index fce90a112..56caa9cc9 100644
> --- a/lib/librte_eal/version.map
> +++ b/lib/librte_eal/version.map
> @@ -318,6 +318,7 @@ EXPERIMENTAL {
> rte_fbarray_find_rev_biggest_free;
> rte_fbarray_find_rev_biggest_used;
> rte_intr_callback_unregister_pending;
> + rte_intr_callback_unregister_sync;
> rte_realloc_socket;
>
> # added in 19.08
> --
> 2.17.2
>
The new symbol should be with other 21.05 additions.
Thanks.
--
David Marchand
[dpdk-dev] [PATCH v5] app/testpmd: support multi-process
From: Lijun Ou
This patch adds multi-process support for testpmd.
The test cmd example as follows:
the primary cmd:
./dpdk-testpmd -a xxx --proc-type=auto -l 0-1 -- -i \
--rxq=4 --txq=4 --num-procs=2 --proc-id=0
the secondary cmd:
./dpdk-testpmd -a xxx --proc-type=auto -l 2-3 -- -i \
--rxq=4 --txq=4 --num-procs=2 --proc-id=1
Signed-off-by: Min Hu (Connor)
Signed-off-by: Lijun Ou
---
v5:
* Fixed run_app.rst for multiple process description.
* Fix compiling error.
v4:
* Fixed minimum vlaue of Rxq or Txq in doc.
v3:
* Fixed compiling error using gcc10.0.
v2:
* Added document for this patch.
---
app/test-pmd/cmdline.c| 12 +++-
app/test-pmd/config.c | 9 ++-
app/test-pmd/parameters.c | 11 +++
app/test-pmd/testpmd.c| 127 ++
app/test-pmd/testpmd.h| 7 ++
doc/guides/testpmd_app_ug/run_app.rst | 95 +
6 files changed, 215 insertions(+), 46 deletions(-)
diff --git a/app/test-pmd/cmdline.c b/app/test-pmd/cmdline.c
index 14110eb..287d7a0 100644
--- a/app/test-pmd/cmdline.c
+++ b/app/test-pmd/cmdline.c
@@ -71,8 +71,6 @@
#include "cmdline_tm.h"
#include "bpf_cmd.h"
-static struct cmdline *testpmd_cl;
-
static void cmd_reconfig_device_queue(portid_t id, uint8_t dev, uint8_t queue);
/* *** Help command with introduction. *** */
@@ -5351,6 +5349,12 @@ cmd_set_flush_rx_parsed(void *parsed_result,
__rte_unused void *data)
{
struct cmd_set_flush_rx *res = parsed_result;
+
+ if (num_procs > 1 && (strcmp(res->mode, "on") == 0)) {
+ printf("multi-process doesn't support to flush rx queues.\n");
+ return;
+ }
+
no_flush_rx = (uint8_t)((strcmp(res->mode, "on") == 0) ? 0 : 1);
}
@@ -17227,6 +17231,10 @@ prompt(void)
printf("Cannot set exit function for cmdline\n");
cmdline_interact(testpmd_cl);
+ if (unlikely(f_quit == 1)) {
+ dup2(testpmd_fd_copy, testpmd_cl->s_in);
+ close(testpmd_fd_copy);
+ }
if (ret != 0)
cmdline_stdin_exit(testpmd_cl);
}
diff --git a/app/test-pmd/config.c b/app/test-pmd/config.c
index ef0b978..e48cbd9 100644
--- a/app/test-pmd/config.c
+++ b/app/test-pmd/config.c
@@ -2827,6 +2827,8 @@ rss_fwd_config_setup(void)
queueid_t rxq;
queueid_t nb_q;
streamid_t sm_id;
+ int start;
+ int end;
nb_q = nb_rxq;
if (nb_q > nb_txq)
@@ -2844,7 +2846,10 @@ rss_fwd_config_setup(void)
init_fwd_streams();
setup_fwd_config_of_each_lcore(&cur_fwd_config);
- rxp = 0; rxq = 0;
+ start = proc_id * nb_q / num_procs;
+ end = start + nb_q / num_procs;
+ rxp = 0;
+ rxq = start;
for (sm_id = 0; sm_id < cur_fwd_config.nb_fwd_streams; sm_id++) {
struct fwd_stream *fs;
@@ -2861,6 +2866,8 @@ rss_fwd_config_setup(void)
continue;
rxp = 0;
rxq++;
+ if (rxq >= end)
+ rxq = start;
}
}
diff --git a/app/test-pmd/parameters.c b/app/test-pmd/parameters.c
index a326c8c..ec3bc62 100644
--- a/app/test-pmd/parameters.c
+++ b/app/test-pmd/parameters.c
@@ -45,6 +45,8 @@
#include
#include "testpmd.h"
+#define PARAM_PROC_ID "proc-id"
+#define PARAM_NUM_PROCS "num-procs"
static void
usage(char* progname)
@@ -644,6 +646,8 @@ launch_args_parse(int argc, char** argv)
{ "rx-mq-mode", 1, 0, 0 },
{ "record-core-cycles", 0, 0, 0 },
{ "record-burst-stats", 0, 0, 0 },
+ { PARAM_NUM_PROCS, 1, 0, 0 },
+ { PARAM_PROC_ID,1, 0, 0 },
{ 0, 0, 0, 0 },
};
@@ -1410,6 +1414,13 @@ launch_args_parse(int argc, char** argv)
record_core_cycles = 1;
if (!strcmp(lgopts[opt_idx].name, "record-burst-stats"))
record_burst_stats = 1;
+
+ if (strncmp(lgopts[opt_idx].name,
+ PARAM_NUM_PROCS, 8) == 0)
+ num_procs = atoi(optarg);
+ if (strncmp(lgopts[opt_idx].name,
+ PARAM_PROC_ID, 7) == 0)
+ proc_id = atoi(optarg);
break;
case 'h':
usage(argv[0]);
diff --git a/app/test-pmd/testpmd.c b/app/test-pmd/testpmd.c
index 96d2e0f..c31234e 100644
--- a/app/test-pmd/testpmd.c
+++ b/app/test-pmd/testpmd.c
@@ -63,6 +63,9 @@
#include "testpmd.h"
+int testpmd_fd_copy; /* the copy of STDIN_FILENO */
+struct cmdline *testpmd_cl;
+
#ifndef MAP_HUGETLB
/* FreeBSD may not have MAP_HUGETLB (in fact, it probably doesn't) */
#define HUGE_FLAG (0x4)
@@ -125,6 +128,9 @@
[dpdk-dev] DPDK Release Status Meeting 25/03/2021
Release status meeting minutes {Date}
=
:Date: 25 March 2021
:toc:
.Agenda:
* Release Dates
* Subtrees
* LTS
* Conferences
* Opens
.Participants:
* Arm
* Canonical
* Debian/Microsoft
* Intel
* Marvell
* Nvidia
* Red Hat
Release Dates
-
* `v21.05` dates
- Proposal/V1 passed, it was on Thursday, 18 March
- -rc1: Thursday, 15 April
- Release:Friday, 14 May
* Please send roadmaps, preferably before beginning of the release
- Thanks to `Marvell`, `Huawei hns3`, `Nvidia`, `Wangxun`, `Intel` and `Arm`
for sending roadmap
Subtrees
* main
- eal patches are under review
** there are many eal patches
- Dmitry reported regression on Windows related memory subsystem
** Need Anatoly's support
- pipeline patches are merged
* next-net
- Progressing, nothing critical, ~80 patches in backlog
- ethdev library changes planned to be merged before -rc1
** expected peak of patches not observed, more driver patches still may
arrive
- pulled from vendor trees yesterday
* next-crypto
- Some patches are merged, nothing critical
- ipsec gateway discussions/reviews are going on
- test/application patches are remaining
* next-eventdev
- "periodic mode for event timer adapter" is merged
- Will be sending new version for Marvell CNXK
** Because of common code dependency it may be postponed to -rc2
- Intel dlb1 remove set merged
- Intel dlb2, new version expected
* next-virtio
- Chenbo is preparing a pull request
- Half of the patches in the backlog reviewed
- There is an RFC from Ilya to use SocketPair Broker to improve vhost in
containers
** It is under review, may be late for 21.05
** It has a dependency external library by Ilya
* next-net-brcm
- Progressing
* next-net-intel
- Progressing
* next-net-mlx
- Progressing, nothing critical
- More patches are due, 1-2 new features are expected
* next-net-mrvl
- Progressing
- Waiting new version of qede patch from Red Hat
LTS
---
* `v19.11.7` is released
-
http://inbox.dpdk.org/dev/20210317170343.3267049-1-christian.ehrha...@canonical.com/
- A regression is reported with 19.11.7
** An 19.11.8-rc will be created, based on interest from stakeholders, and
test reports received, and early 19.11.8 can be released.
If there is no enough interest fix will wait regular 19.11.8 cycle
* `v20.11.1` is released
- http://inbox.dpdk.org/dev/20210308181351.409609-1-luca.bocca...@gmail.com/
Conferences
---
* DPDK APAC 2021 event was on 22-23 March, presentations can be found at:
- https://events.linuxfoundation.org/dpdk-summit-apac/program/schedule/
Opens
-
* Security issues
- The resourcing discussed in the governing board, the role requires a trusted
name but chain of trust can be accepted.
** Can discuss the possible candidate(s) again in next techboard meeting
** It will be good to have an assigned resource for security issues
- Why most of the issues are in vhost/virtio domain?
** vhost is the interface to untrusted domain
** vhost is easier to test by security researchers, it doesn't require any
specific hardware
.DPDK Release Status Meetings
*
The DPDK Release Status Meeting is intended for DPDK Committers to discuss the
status of the master tree and sub-trees, and for project managers to track
progress or milestone dates.
The meeting occurs on every Thursdays at 8:30 UTC. on https://meet.jit.si/DPDK
If you wish to attend just send an email to
"John McNamara " for the invite.
*
Re: [dpdk-dev] [Linuxarm] [PATCH V2 0/4] add Hisilicon kunpeng CPU support
在 2021/3/25 20:19, Thomas Monjalon 写道: 25/03/2021 12:17, oulijun: Ruifeng has reviewed-by. Does anyone else have any comments? Is it necessary to send the V2? v2 for what? There is a change? No. no change. 在 2021/3/25 17:07, Thomas Monjalon 写道: 25/03/2021 09:54, oulijun: Hi, Thomas&&Ferruh Do I need to send a patchset? ??? What do you mean? 在 2021/3/10 9:35, Lijun Ou 写道: This series add meson build for Hisilicon kunpeng CPU. Lijun Ou (4): config/arm: add Hisilicon kunpeng920 implementer config/arm: add Hisilicon kunpeng930 implementer config/arm: add kunpeng920 meson cross compile target config/arm: add kunpeng930 meson cross compile target . .
Re: [dpdk-dev] [PATCH v4] app/testpmd: support multi-process
在 2021/3/24 16:08, Li, Xiaoyun 写道:
Hi
-Original Message-
From: dev On Behalf Of Min Hu (Connor)
Sent: Monday, March 22, 2021 15:07
To: dev@dpdk.org
Cc: Yigit, Ferruh ; ajit.khapa...@broadcom.com
Subject: [dpdk-dev] [PATCH v4] app/testpmd: support multi-process
From: Lijun Ou
This patch adds multi-process support for testpmd.
The test cmd example as follows:
the primary cmd:
./dpdk-testpmd -a xxx --proc-type=auto -l 0-1 -- -i \
--rxq=4 --txq=4 --num-procs=2 --proc-id=0
the secondary cmd:
./dpdk-testpmd -a xxx --proc-type=auto -l 2-3 -- -i \
--rxq=4 --txq=4 --num-procs=2 --proc-id=1
Signed-off-by: Min Hu (Connor)
Signed-off-by: Lijun Ou
---
v4:
* Fixed minimum vlaue of Rxq or Txq in doc.
v3:
* Fixed compiling error using gcc10.0.
v2:
* Added document for this patch.
---
app/test-pmd/cmdline.c| 12 ++-
app/test-pmd/config.c | 9 ++-
app/test-pmd/parameters.c | 11 +++
app/test-pmd/testpmd.c| 138 ++
app/test-pmd/testpmd.h| 7 ++
doc/guides/testpmd_app_ug/run_app.rst | 69 +
6 files changed, 196 insertions(+), 50 deletions(-)
+ if (rte_eal_process_type() == RTE_PROC_PRIMARY)
+ rte_mp = rte_pktmbuf_pool_create(pool_name,
+nb_mbuf, mb_mempool_cache, 0,
+mbuf_seg_size, heap_socket);
+ else
+ rte_mp = rte_mempool_lookup(pool_name);
+
break;
}
case MP_ALLOC_XBUF:
What about this one when users use external bufs? Why not addressing secondary
process here?
If it works for all cases, you should add a condition at the start of this
function, if it's secondary, goto err to check mp and return.
Yes, your are right, I have fixed it in v5, thanks.
@@ -1994,6 +2013,12 @@ flush_fwd_rx_queues(void)
uint64_t prev_tsc = 0, diff_tsc, cur_tsc, timer_tsc = 0;
uint64_t timer_period;
+ if (num_procs > 1) {
+ printf("multi-process not support for flushing fwd rx "
+ "queues, skip the below lines and return.\n");
+uint8_t f_quit;
+int testpmd_fd_copy;
+struct cmdline *testpmd_cl;
+
Please address the compilation failure on patchwork related to these variables
(multiple definitions).
Done in v5.
+.. code-block:: console
+
+ primary process:
+sudo ./dpdk-testpmd -a xxx --proc-type=auto -l 0-1 -- -i --rxq=4
+--txq=4 --num-procs=2 --proc-id=0
+
+ secondary process:
+ sudo ./dpdk-testpmd -a xxx --proc-type=auto -l 2-3 -- -i --rxq=4
+--txq=4 --num-procs=2 --proc-id=1
+
+* ``--rxq=N``
+
+Set the number of RX queues per port to N, where 1 <= N <= 65535.
+The default value is 1. N is the sum of queues used by primary and
secondary
process.
+
Did you upstream wrong patch?
You said you would address the queue number issue Ajit Khaparde mentioned but
you didn't in this patch.
The number of queues should be a multiple of the number of processes?
Done in v5.
+* ``--txq=N``
+
+Set the number of TX queues per port to N, where 1 <= N <= 65535.
+The default value is 1. N is the sum of queues used by primary and
secondary
process.
+
Same as above.
+* ``--num-procs=N``
+Most dev ops is supported in primary and secondary process. While
+secondary process is not permitted to allocate or release shared memory, so
some ops are not supported as follows:
+``dev_start``
+``dev_stop``
+``rx_queue_setup``
+``tx_queue_setup``
+``rx_queue_release``
+``tx_queue_release``
What about some config commands?
Such as "clear port stats all". Should this be allowed by secondary?
>
I think so, actually, all the queues is visible to primary and
secondary. The only thing we do is to separate queues for different
process for io (packets) in Rx/Tx. It is of for secondary "clear port
stats all".
And like "port config all rxq". If primary hasn't started ports, should the
secondary allowed to change traffic related stuff (offloads, rx/txd, rx/txq and so on)?
Yes, port config all rxq/txq/rxd/txd/offload is not supported in the
secondary process. It has been done in v5.
+
+RTE_FLOW supported, it applies only on its own process on SW side, but all on
HW size.
About rte flow, what do you mean apply only on its own process on SW side?
If I set number-procs=2, rxq=4
Then on secondary process, I set a flow which directs 192.168.0.1 traffic to
queue 0. It seems it will directs this kind of traffic to primary process. But
I can't see this rule from primary process side.
Is this behavior right for multiple process?
According to doc rte_flow.rst, we maintain flow rules in process level:
primary and secondary has its own flow list(but one flow list in HW).
As previously mentioned, the two can see all the queues, so setting the
flow rules for the other i
Re: [dpdk-dev] [PATCH] librte_eal: add APIs to speedup virt2iova/phys
Hello, On Mon, Apr 20, 2020 at 4:13 PM Li Feng wrote: > > Cool, thank you, Anatoly and Kozlyuk. > > I haven't found how Windows implements the rte_mem_virt2phy. > > Using an opaque structure pointer as the first argument is a good idea. I pinged about this patch status 6 months ago but got no reply. Trying again in public. >From the thread, I understand that at best it would have to be done >differently. -- David Marchand
Re: [dpdk-dev] [dpdk-stable] [PATCH] mem: fix free segment when using huge-unlink option
Hello,
On Mon, Mar 1, 2021 at 11:44 AM Burakov, Anatoly
wrote:
>
> On 28-Feb-21 1:21 PM, Roy Shterman wrote:
> >
> >
> > On Mon, Feb 22, 2021 at 5:53 PM Burakov, Anatoly
> > mailto:anatoly.bura...@intel.com>> wrote:
> >
> > On 22-Feb-21 10:41 AM, Roy Shterman wrote:
> > > When using huge_unlink we unlink the segment right
> > > after allocation. Although we unlink the file we keep
> > > the fd in fd_list so file still exist just the path deleted.
> > > When freeing the hugepage we need to close the fd and assign
> > > it with (-1) in fd_list for the page to be released.
> > >
> > > The current flow fails rte_malloc in the following flow when working
> > > with --huge-unlink option:
> > > 1. alloc_seg() for segment A -
> > > We allocate segment, unlink the path to the segment
> > > and keep the file descriptor in fd_list.
> > > 2. free_seg() for segment A -
> > > We clear the segment metadata and return - without closing fd
> > > or assigning (-1) in fd list.
> > > 3. alloc_seg() for segment A again -
> > > We find segment A as available, try to allocate it,
> > > find the old fd in fd_list try to unlink it
> > > as part of alloc_seg() but failed because path doesn't exist.
> > >
> > > The impact of such error is falsly failing rte_malloc()
> > > although we have hugepages available.
> > >
> > > Fixes: d435aad37da7 ("mem: support --huge-unlink mode")
> > >
> > > Signed-off-by: Roy Shterman > >
> >
> > Cc: sta...@dpdk.org
> >
> > Provisionally, patch looks fine, but i'll have to have a closer look.
> >
> >
> > Hi Anatoly,
> >
> > Do I need to send this patch also to stable or it will happen
> > automatically if the patch will reach the next release candidate?
>
> Not automatically, generally you should add a CC to stable for the patch
> to be considered as part of stable release. That said, usually Fixed:
> tag is also used to determine whether a patch is backport-able, so
> having a correctly identified Fixed: tag is a mandatory minimum :)
>
> > Also I wonder if you had more time to review this one?
>
> Not yet, but i'll try to make some time this week.
Any update?
Thanks.
--
David Marchand
Re: [dpdk-dev] [PATCH v4] eal: fix create user mem map repeatedly when it exists
Friendly ping.
> -Original Message-
> From: wangyunjian
> Sent: Monday, December 7, 2020 7:09 PM
> To: dev@dpdk.org
> Cc: david.march...@redhat.com; tho...@monjalon.net;
> anatoly.bura...@intel.com; Lilijun (Jerry) ;
> xudingke
> ; wangyunjian ;
> sta...@dpdk.org
> Subject: [dpdk-dev] [PATCH v4] eal: fix create user mem map repeatedly when it
> exists
>
> From: Yunjian Wang
>
> Currently, user mem maps will check if the newly mapped area is adjacent to
> any existing mapping, but will not check if the mapping is identical because
> it
> assumes that the API will never get called with the same mapping twice. This
> will result in duplicate entries in the user mem maps list.
>
> Fix it by also checking for duplicate mappings, and skipping them if they are
> found.
>
> Fixes: 0cbce3a167f1 ("vfio: skip DMA map failure if already mapped")
> Cc: sta...@dpdk.org
>
> Signed-off-by: Yunjian Wang
> Acked-by: Anatoly Burakov
> ---
> v4:
> Update commit log suggested by Anatoly Burakov
> ---
> lib/librte_eal/linux/eal_vfio.c | 5 +
> 1 file changed, 5 insertions(+)
>
> diff --git a/lib/librte_eal/linux/eal_vfio.c
> b/lib/librte_eal/linux/eal_vfio.c index
> 050082444e..0967215783 100644
> --- a/lib/librte_eal/linux/eal_vfio.c
> +++ b/lib/librte_eal/linux/eal_vfio.c
> @@ -168,6 +168,10 @@ adjust_map(struct user_mem_map *src, struct
> user_mem_map *end, static int merge_map(struct user_mem_map *left,
> struct user_mem_map *right) {
> + /* merge the same maps into one */
> + if (memcmp(left, right, sizeof(struct user_mem_map)) == 0)
> + goto out;
> +
> if (left->addr + left->len != right->addr)
> return 0;
> if (left->iova + left->len != right->iova) @@ -175,6 +179,7 @@
> merge_map(struct user_mem_map *left, struct user_mem_map *right)
>
> left->len += right->len;
>
> +out:
> memset(right, 0, sizeof(*right));
>
> return 1;
> --
> 2.23.0
Re: [dpdk-dev] [dpdk-dev v21.11] [PATCH v5 8/8] eventdev: simplify Rx adapter event vector config
>> From: pbhagavat...@marvell.com
>> Sent: Wednesday, March 24, 2021 10:35 AM
>> To: jer...@marvell.com; Jayatheerthan, Jay
>; Carrillo, Erik G
>; Gujjar,
>> Abhinandan S ; McDaniel, Timothy
>; hemant.agra...@nxp.com; Van
>> Haaren, Harry ; mattias.ronnblom
>; Ma, Liang J
>> ; Ray Kinsella ; Neil Horman
>
>> Cc: dev@dpdk.org; Pavan Nikhilesh
>> Subject: [dpdk-dev v21.11] [PATCH v5 8/8] eventdev: simplify Rx
>adapter event vector config
>>
>> From: Pavan Nikhilesh
>>
>> Include vector configuration into the structure
>> ``rte_event_eth_rx_adapter_queue_conf`` used when configuring rest
>> of the Rx adapter ethernet device Rx queue parameters.
>> This simplifies event vector configuration as it avoids splitting
>> configuration per Rx queue.
>>
>> Signed-off-by: Pavan Nikhilesh
>> ---
>> app/test-eventdev/test_pipeline_common.c | 16 +-
>> lib/librte_eventdev/eventdev_pmd.h| 29 ---
>> .../rte_event_eth_rx_adapter.c| 168 ++
>> .../rte_event_eth_rx_adapter.h| 27 ---
>> lib/librte_eventdev/version.map | 1 -
>> 5 files changed, 57 insertions(+), 184 deletions(-)
>>
>> diff --git a/app/test-eventdev/test_pipeline_common.c b/app/test-
>eventdev/test_pipeline_common.c
>> index d5ef90500..76aee254b 100644
>> --- a/app/test-eventdev/test_pipeline_common.c
>> +++ b/app/test-eventdev/test_pipeline_common.c
>> @@ -331,7 +331,6 @@ pipeline_event_rx_adapter_setup(struct
>evt_options *opt, uint8_t stride,
>> uint16_t prod;
>> struct rte_mempool *vector_pool = NULL;
>> struct rte_event_eth_rx_adapter_queue_conf queue_conf;
>> -struct rte_event_eth_rx_adapter_event_vector_config
>vec_conf;
>>
>> memset(&queue_conf, 0,
>> sizeof(struct
>rte_event_eth_rx_adapter_queue_conf));
>> @@ -397,8 +396,12 @@ pipeline_event_rx_adapter_setup(struct
>evt_options *opt, uint8_t stride,
>> }
>>
>> if (cap &
>RTE_EVENT_ETH_RX_ADAPTER_CAP_EVENT_VECTOR) {
>> +queue_conf.vector_sz = opt-
>>vector_size;
>> +queue_conf.vector_timeout_ns =
>> +opt->vector_tmo_nsec;
>> queue_conf.rx_queue_flags |=
>>
> RTE_EVENT_ETH_RX_ADAPTER_QUEUE_EVENT_VECTOR;
>> +queue_conf.vector_mp = vector_pool;
>> } else {
>> evt_err("Rx adapter doesn't support
>event vector");
>> return -EINVAL;
>> @@ -418,17 +421,6 @@ pipeline_event_rx_adapter_setup(struct
>evt_options *opt, uint8_t stride,
>> return ret;
>> }
>>
>> -if (opt->ena_vector) {
>> -vec_conf.vector_sz = opt->vector_size;
>> -vec_conf.vector_timeout_ns = opt-
>>vector_tmo_nsec;
>> -vec_conf.vector_mp = vector_pool;
>> -if
>(rte_event_eth_rx_adapter_queue_event_vector_config(
>> -prod, prod, -1, &vec_conf) < 0) {
>> -evt_err("Failed to configure event
>vectorization for Rx adapter");
>> -return -EINVAL;
>> -}
>> -}
>> -
>> if (!(cap &
>RTE_EVENT_ETH_RX_ADAPTER_CAP_INTERNAL_PORT)) {
>> uint32_t service_id = -1U;
>>
>> diff --git a/lib/librte_eventdev/eventdev_pmd.h
>b/lib/librte_eventdev/eventdev_pmd.h
>> index 0f724ac85..63b3bc4b5 100644
>> --- a/lib/librte_eventdev/eventdev_pmd.h
>> +++ b/lib/librte_eventdev/eventdev_pmd.h
>> @@ -667,32 +667,6 @@ typedef int
>(*eventdev_eth_rx_adapter_vector_limits_get_t)(
>> const struct rte_eventdev *dev, const struct rte_eth_dev
>*eth_dev,
>> struct rte_event_eth_rx_adapter_vector_limits *limits);
>>
>> -struct rte_event_eth_rx_adapter_event_vector_config;
>> -/**
>> - * Enable event vector on an given Rx queue of a ethernet devices
>belonging to
>> - * the Rx adapter.
>> - *
>> - * @param dev
>> - * Event device pointer
>> - *
>> - * @param eth_dev
>> - * Ethernet device pointer
>> - *
>> - * @param rx_queue_id
>> - * The Rx queue identifier
>> - *
>> - * @param config
>> - * Pointer to the event vector configuration structure.
>> - *
>> - * @return
>> - * - 0: Success.
>> - * - <0: Error code returned by the driver function.
>> - */
>> -typedef int (*eventdev_eth_rx_adapter_event_vector_config_t)(
>> -const struct rte_eventdev *dev, const struct rte_eth_dev
>*eth_dev,
>> -int32_t rx_queue_id,
>> -const struct rte_event_eth_rx_adapter_event_vector_config
>*config);
>> -
>> typedef uint32_t rte_event_pmd_selftest_seqn_t;
>> extern int rte_event_pmd_selftest_seqn_dynfield_offset;
>>
>> @@ -1118,9 +1092,6 @@ struct rte_eventdev_ops {
>> eventdev_eth_rx_adapter_vector_limits_get_t
>> eth_rx_adapter_vector_limits_get;
>> /**< Get event vector
[dpdk-dev] DPDKthe packet capture performance increases steeply between 11 Rx queues and 12 Rx queues. Any idea why?
Hi, We are experimenting with testpmd packet generation and capture at 100 Gbps on two machines back to back. We are observing a peculiar behaviour that the packet capture performance increases steeply between 11 Rx queues and 12 Rx queues. Any idea why? The details of the setup are given below: DPDK version: *19.11* NIC: *Mellanox ConnectX-5 100 GbE * OS: *RHEL 8.2(kernel *4.18.0-193) Application: *Testpmd(txonly on generation side and rxonly on capture side)* *It is observed that *capture rate increases almost gradually upto* 11 Rx queues and then increases steeply *to reach line rate *at 12 queues. The maximum capture rate with 11 Rx queues is around 80 Gbps and with 12 Rx queues is 99. Gbps.* *Is it something to do with DPDK ? Or Mellanox specific?* -- Regards Rajesh R
[dpdk-dev] [PATCH v2 0/4] telemetry logging improvements and cleanup
This set adds support for using the regular rte_log functions from the telemetry
library; avoiding circular dependencies by having EAL register the telemetry
library itself and then passing the required handles to that library as part of
the telemetry_init call.
Beyond this change, the other three patches are cleanups to ensure that all
internal functions are clearly separate from the public APIs. (Patches 3 & 4 may
be merged into a single one on apply, for I've kept them separate for now for
clarity).
V2: Rebased on latest main branch.
Bruce Richardson (4):
telemetry: use rte_log for logging
telemetry: make the legacy registration function internal
telemetry: rename internal-only header file
telemetry: move init function to internal header
doc/guides/rel_notes/release_21_05.rst| 5 ++
lib/librte_eal/freebsd/eal.c | 12 +--
lib/librte_eal/linux/eal.c| 12 +--
lib/librte_metrics/rte_metrics_telemetry.c| 2 +-
lib/librte_telemetry/rte_telemetry.h | 25 --
lib/librte_telemetry/telemetry.c | 76 +--
...elemetry_legacy.h => telemetry_internal.h} | 41 +-
lib/librte_telemetry/telemetry_legacy.c | 2 +-
lib/librte_telemetry/version.map | 2 +-
9 files changed, 87 insertions(+), 90 deletions(-)
rename lib/librte_telemetry/{rte_telemetry_legacy.h => telemetry_internal.h}
(65%)
--
2.27.0
[dpdk-dev] [PATCH v2 1/4] telemetry: use rte_log for logging
Rather than passing back an error string to the caller, take as input the
rte_log function to use, and just use regular logging.
Signed-off-by: Bruce Richardson
Acked-by: Ciara Power
---
lib/librte_eal/freebsd/eal.c | 10 ++--
lib/librte_eal/linux/eal.c | 10 ++--
lib/librte_telemetry/rte_telemetry.h | 15 --
lib/librte_telemetry/telemetry.c | 74 +---
4 files changed, 50 insertions(+), 59 deletions(-)
diff --git a/lib/librte_eal/freebsd/eal.c b/lib/librte_eal/freebsd/eal.c
index 62320d610..97ce9976c 100644
--- a/lib/librte_eal/freebsd/eal.c
+++ b/lib/librte_eal/freebsd/eal.c
@@ -941,16 +941,12 @@ rte_eal_init(int argc, char **argv)
return -1;
}
if (!internal_conf->no_telemetry) {
- const char *error_str = NULL;
+ uint32_t tlog = rte_log_register_type_and_pick_level(
+ "lib.telemetry", RTE_LOG_WARNING);
if (rte_telemetry_init(rte_eal_get_runtime_dir(),
rte_version(),
- &internal_conf->ctrl_cpuset, &error_str)
- != 0) {
- rte_eal_init_alert(error_str);
+ &internal_conf->ctrl_cpuset, rte_log, tlog) !=
0)
return -1;
- }
- if (error_str != NULL)
- RTE_LOG(NOTICE, EAL, "%s\n", error_str);
}
eal_mcfg_complete();
diff --git a/lib/librte_eal/linux/eal.c b/lib/librte_eal/linux/eal.c
index 9ffb4b331..f6dd67b6d 100644
--- a/lib/librte_eal/linux/eal.c
+++ b/lib/librte_eal/linux/eal.c
@@ -1314,16 +1314,12 @@ rte_eal_init(int argc, char **argv)
return -1;
}
if (!internal_conf->no_telemetry) {
- const char *error_str = NULL;
+ uint32_t tlog = rte_log_register_type_and_pick_level(
+ "lib.telemetry", RTE_LOG_WARNING);
if (rte_telemetry_init(rte_eal_get_runtime_dir(),
rte_version(),
- &internal_conf->ctrl_cpuset, &error_str)
- != 0) {
- rte_eal_init_alert(error_str);
+ &internal_conf->ctrl_cpuset, rte_log, tlog) !=
0)
return -1;
- }
- if (error_str != NULL)
- RTE_LOG(NOTICE, EAL, "%s\n", error_str);
}
eal_mcfg_complete();
diff --git a/lib/librte_telemetry/rte_telemetry.h
b/lib/librte_telemetry/rte_telemetry.h
index 027b048d7..d38894b97 100644
--- a/lib/librte_telemetry/rte_telemetry.h
+++ b/lib/librte_telemetry/rte_telemetry.h
@@ -294,6 +294,12 @@ rte_telemetry_register_cmd(const char *cmd, telemetry_cb
fn, const char *help);
#ifdef RTE_HAS_CPUSET
+/**
+ * @internal
+ * Log function type, to allow passing as parameter if necessary
+ */
+typedef int (*rte_log_fn)(uint32_t level, uint32_t logtype, const char
*format, ...);
+
/**
* @internal
* Initialize Telemetry.
@@ -302,9 +308,10 @@ rte_telemetry_register_cmd(const char *cmd, telemetry_cb
fn, const char *help);
* The runtime directory of DPDK.
* @param cpuset
* The CPU set to be used for setting the thread affinity.
- * @param err_str
- * This err_str pointer should point to NULL on entry. In the case of an error
- * or warning, it will be non-NULL on exit.
+ * @param log_fn
+ * Function pointer to the rte_log function for logging use
+ * @param registered_logtype
+ * The registered log type to use for logging
*
* @return
* 0 on success.
@@ -314,7 +321,7 @@ rte_telemetry_register_cmd(const char *cmd, telemetry_cb
fn, const char *help);
__rte_internal
int
rte_telemetry_init(const char *runtime_dir, const char *rte_version,
rte_cpuset_t *cpuset,
- const char **err_str);
+ rte_log_fn log_fn, uint32_t registered_logtype);
#endif /* RTE_HAS_CPUSET */
diff --git a/lib/librte_telemetry/telemetry.c b/lib/librte_telemetry/telemetry.c
index 14b4ff5ea..042136b82 100644
--- a/lib/librte_telemetry/telemetry.c
+++ b/lib/librte_telemetry/telemetry.c
@@ -15,6 +15,7 @@
#include
#include
#include
+#include
#include "rte_telemetry.h"
#include "telemetry_json.h"
@@ -49,7 +50,14 @@ static struct socket v1_socket; /* socket for v1 telemetry */
#endif /* !RTE_EXEC_ENV_WINDOWS */
static const char *telemetry_version; /* save rte_version */
-static char telemetry_log_error[1024]; /* Will contain error on init failure */
+static const char *socket_dir;/* runtime directory */
+static rte_cpuset_t *thread_cpuset;
+static rte_log_fn rte_log_ptr;
+static uint32_t logtype;
+
+#define TMTY_LOG(l, ...) \
+rte_log_ptr(RTE_LOG_ ## l, logtype, "TELEMETRY: " __VA_ARGS__)
+
/* list of command callbacks, with one command registered by default */
static struct cmd_callback callbacks[TELEMET
[dpdk-dev] [PATCH v2 2/4] telemetry: make the legacy registration function internal
The function for registration of callbacks for legacy telemetry was
documented as internal-only in the API documents, but marked as
experimental in the version.map file. Since this is an internal-only
function, for consistency we update the version mapping to have it as
internal.
Signed-off-by: Bruce Richardson
Acked-by: Ciara Power
---
doc/guides/rel_notes/release_21_05.rst | 5 +
lib/librte_telemetry/rte_telemetry_legacy.h | 2 +-
lib/librte_telemetry/version.map| 2 +-
3 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/doc/guides/rel_notes/release_21_05.rst
b/doc/guides/rel_notes/release_21_05.rst
index 8e686cc62..fb965fec3 100644
--- a/doc/guides/rel_notes/release_21_05.rst
+++ b/doc/guides/rel_notes/release_21_05.rst
@@ -148,6 +148,11 @@ ABI Changes
* No ABI change that would break compatibility with 20.11.
+* The experimental function ``rte_telemetry_legacy_register`` has been
+ removed from the public API and is now an internal-only function. This
+ function was already marked as internal in the API documentation for it,
+ and was not for use by external applications.
+
Known Issues
diff --git a/lib/librte_telemetry/rte_telemetry_legacy.h
b/lib/librte_telemetry/rte_telemetry_legacy.h
index c83f9a8d9..fb4474018 100644
--- a/lib/librte_telemetry/rte_telemetry_legacy.h
+++ b/lib/librte_telemetry/rte_telemetry_legacy.h
@@ -78,7 +78,7 @@ legacy_client_handler(void *sock_id);
* @return
* -ENOENT if max callbacks limit has been reached.
*/
-__rte_experimental
+__rte_internal
int
rte_telemetry_legacy_register(const char *cmd,
enum rte_telemetry_legacy_data_req data_req,
diff --git a/lib/librte_telemetry/version.map b/lib/librte_telemetry/version.map
index ec0ebc1be..bde80ce29 100644
--- a/lib/librte_telemetry/version.map
+++ b/lib/librte_telemetry/version.map
@@ -14,12 +14,12 @@ EXPERIMENTAL {
rte_tel_data_start_array;
rte_tel_data_start_dict;
rte_tel_data_string;
- rte_telemetry_legacy_register;
rte_telemetry_register_cmd;
local: *;
};
INTERNAL {
+ rte_telemetry_legacy_register;
rte_telemetry_init;
};
--
2.27.0
[dpdk-dev] [PATCH v2 3/4] telemetry: rename internal-only header file
The header file containing the legacy telemetry function prototypes was all
internal-only, so we rename the file to be an internal-only one to make it
clearer it's not for installation.
Signed-off-by: Bruce Richardson
Acked-by: Ciara Power
---
lib/librte_metrics/rte_metrics_telemetry.c | 2 +-
lib/librte_telemetry/telemetry.c| 2 +-
.../{rte_telemetry_legacy.h => telemetry_internal.h}| 6 +++---
lib/librte_telemetry/telemetry_legacy.c | 2 +-
4 files changed, 6 insertions(+), 6 deletions(-)
rename lib/librte_telemetry/{rte_telemetry_legacy.h => telemetry_internal.h}
(93%)
diff --git a/lib/librte_metrics/rte_metrics_telemetry.c
b/lib/librte_metrics/rte_metrics_telemetry.c
index 795bd29fe..c24990d92 100644
--- a/lib/librte_metrics/rte_metrics_telemetry.c
+++ b/lib/librte_metrics/rte_metrics_telemetry.c
@@ -5,7 +5,7 @@
#include
#include
#ifdef RTE_LIB_TELEMETRY
-#include
+#include
#endif
#include "rte_metrics.h"
diff --git a/lib/librte_telemetry/telemetry.c b/lib/librte_telemetry/telemetry.c
index 042136b82..7e08afd22 100644
--- a/lib/librte_telemetry/telemetry.c
+++ b/lib/librte_telemetry/telemetry.c
@@ -20,7 +20,7 @@
#include "rte_telemetry.h"
#include "telemetry_json.h"
#include "telemetry_data.h"
-#include "rte_telemetry_legacy.h"
+#include "telemetry_internal.h"
#define MAX_CMD_LEN 56
#define MAX_HELP_LEN 64
diff --git a/lib/librte_telemetry/rte_telemetry_legacy.h
b/lib/librte_telemetry/telemetry_internal.h
similarity index 93%
rename from lib/librte_telemetry/rte_telemetry_legacy.h
rename to lib/librte_telemetry/telemetry_internal.h
index fb4474018..ad076b911 100644
--- a/lib/librte_telemetry/rte_telemetry_legacy.h
+++ b/lib/librte_telemetry/telemetry_internal.h
@@ -2,8 +2,8 @@
* Copyright(c) 2020 Intel Corporation
*/
-#ifndef _RTE_TELEMETRY_LEGACY_H_
-#define _RTE_TELEMETRY_LEGACY_H_
+#ifndef _RTE_TELEMETRY_INTERNAL_H_
+#define _RTE_TELEMETRY_INTERNAL_H_
#include
#include "rte_telemetry.h"
@@ -14,7 +14,7 @@
* @b EXPERIMENTAL: this API may change without prior notice
* @file
- * RTE Telemetry Legacy
+ * RTE Telemetry Legacy and internal definitions
*
***/
diff --git a/lib/librte_telemetry/telemetry_legacy.c
b/lib/librte_telemetry/telemetry_legacy.c
index edd76ca35..5e9af37db 100644
--- a/lib/librte_telemetry/telemetry_legacy.c
+++ b/lib/librte_telemetry/telemetry_legacy.c
@@ -15,7 +15,7 @@
#include
#include
-#include "rte_telemetry_legacy.h"
+#include "telemetry_internal.h"
#define MAX_LEN 128
#define BUF_SIZE 1024
--
2.27.0
[dpdk-dev] [PATCH v2 4/4] telemetry: move init function to internal header
The rte_telemetry_init() function is for EAL use only, so can be moved to the internal header rather than being in the public one. Signed-off-by: Bruce Richardson Acked-by: Ciara Power --- lib/librte_eal/freebsd/eal.c | 2 +- lib/librte_eal/linux/eal.c| 2 +- lib/librte_telemetry/rte_telemetry.h | 32 -- lib/librte_telemetry/telemetry_internal.h | 33 +++ 4 files changed, 35 insertions(+), 34 deletions(-) diff --git a/lib/librte_eal/freebsd/eal.c b/lib/librte_eal/freebsd/eal.c index 97ce9976c..32442e5ba 100644 --- a/lib/librte_eal/freebsd/eal.c +++ b/lib/librte_eal/freebsd/eal.c @@ -42,7 +42,7 @@ #include #include #include -#include +#include #include "eal_private.h" #include "eal_thread.h" diff --git a/lib/librte_eal/linux/eal.c b/lib/librte_eal/linux/eal.c index f6dd67b6d..abbb53774 100644 --- a/lib/librte_eal/linux/eal.c +++ b/lib/librte_eal/linux/eal.c @@ -49,8 +49,8 @@ #include #include #include -#include +#include #include "eal_private.h" #include "eal_thread.h" #include "eal_internal_cfg.h" diff --git a/lib/librte_telemetry/rte_telemetry.h b/lib/librte_telemetry/rte_telemetry.h index d38894b97..fd57718c2 100644 --- a/lib/librte_telemetry/rte_telemetry.h +++ b/lib/librte_telemetry/rte_telemetry.h @@ -292,38 +292,6 @@ __rte_experimental int rte_telemetry_register_cmd(const char *cmd, telemetry_cb fn, const char *help); -#ifdef RTE_HAS_CPUSET - -/** - * @internal - * Log function type, to allow passing as parameter if necessary - */ -typedef int (*rte_log_fn)(uint32_t level, uint32_t logtype, const char *format, ...); - -/** - * @internal - * Initialize Telemetry. - * - * @param runtime_dir - * The runtime directory of DPDK. - * @param cpuset - * The CPU set to be used for setting the thread affinity. - * @param log_fn - * Function pointer to the rte_log function for logging use - * @param registered_logtype - * The registered log type to use for logging - * - * @return - * 0 on success. - * @return - * -1 on failure. - */ -__rte_internal -int -rte_telemetry_init(const char *runtime_dir, const char *rte_version, rte_cpuset_t *cpuset, - rte_log_fn log_fn, uint32_t registered_logtype); - -#endif /* RTE_HAS_CPUSET */ /** * Get a pointer to a container with memory allocated. The container is to be diff --git a/lib/librte_telemetry/telemetry_internal.h b/lib/librte_telemetry/telemetry_internal.h index ad076b911..6c5200604 100644 --- a/lib/librte_telemetry/telemetry_internal.h +++ b/lib/librte_telemetry/telemetry_internal.h @@ -84,4 +84,37 @@ rte_telemetry_legacy_register(const char *cmd, enum rte_telemetry_legacy_data_req data_req, telemetry_legacy_cb fn); +#ifdef RTE_HAS_CPUSET + +/** + * @internal + * Log function type, to allow passing as parameter if necessary + */ +typedef int (*rte_log_fn)(uint32_t level, uint32_t logtype, const char *format, ...); + +/** + * @internal + * Initialize Telemetry. + * + * @param runtime_dir + * The runtime directory of DPDK. + * @param cpuset + * The CPU set to be used for setting the thread affinity. + * @param log_fn + * Function pointer to the rte_log function for logging use + * @param registered_logtype + * The registered log type to use for logging + * + * @return + * 0 on success. + * @return + * -1 on failure. + */ +__rte_internal +int +rte_telemetry_init(const char *runtime_dir, const char *rte_version, rte_cpuset_t *cpuset, + rte_log_fn log_fn, uint32_t registered_logtype); + +#endif /* RTE_HAS_CPUSET */ + #endif -- 2.27.0
Re: [dpdk-dev] [PATCH v2 1/4] telemetry: use rte_log for logging
On Thu, Mar 25, 2021 at 2:57 PM Bruce Richardson wrote: > > Rather than passing back an error string to the caller, take as input the > rte_log function to use, and just use regular logging. > > Signed-off-by: Bruce Richardson > Acked-by: Ciara Power I guess this replaces http://patchwork.dpdk.org/project/dpdk/patch/20210308222339.819494-1-tho...@monjalon.net/ ? -- David Marchand
Re: [dpdk-dev] [PATCH] maintainers: update for telemetry
On 25/03/2021 11:53, Ciara Power wrote: Replace Kevin Laatz with Ciara Power. Signed-off-by: Ciara Power --- MAINTAINERS | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/MAINTAINERS b/MAINTAINERS index 0f5e745cd0..0ec5588540 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -1527,7 +1527,7 @@ F: lib/librte_latencystats/ F: app/test/test_latencystats.c Telemetry - EXPERIMENTAL -M: Kevin Laatz +M: Ciara Power F: lib/librte_telemetry/ F: app/test/test_telemetry* F: usertools/dpdk-telemetry* Acked-by: Kevin Laatz
Re: [dpdk-dev] [PATCH v2 1/2] vhost: Add API to get negotiated protocol features
On 3/22/21 8:22 AM, Keiichi Watanabe wrote: > Add rte_vhost_get_negotiated_protocol_features, which returns a set of > enabled protocol features. > > Signed-off-by: Keiichi Watanabe > --- > lib/librte_vhost/rte_vhost.h | 15 +++ > lib/librte_vhost/version.map | 1 + > lib/librte_vhost/vhost.c | 14 ++ > 3 files changed, 30 insertions(+) > Reviewed-by: Maxime Coquelin Thanks, Maxime
Re: [dpdk-dev] [PATCH] tailq: secondary process may not have all tailq available
On Mon, Jan 18, 2021 at 6:55 AM Hemant Agrawal wrote: > On 1/14/2021 7:14 PM, David Marchand wrote: > > On Thu, Jan 14, 2021 at 8:24 AM Hemant Agrawal > > wrote: > >> Secondary process may not have all the tailq available for > >> mapping, so better to ignore the error. > >> > >> e.g. if the primary process is linked with N libs > >> and secondary process is linked with less number of libs. > >> > >> dpdk-procinfo results into following error: > >> EAL: Cannot initialize tailq: VMBUS_RESOURCE_LIST > > For dpdk-procinfo to complain about vmbus, it means the bus driver has > > been loaded in the secondary, but not in the primary. > > Is this what you intend to do? > > > Yes. > > Typically the customer applications are built/linked with only limited > number of bus, devices > > dpdk-procinfo is getting compiled with default list as part of dpdk > build. so, if customer is trying to use the default dpdk-procinfo with > their application - there will be differences. > Is this a usecase that we support or we want to support? Thanks. -- David Marchand
Re: [dpdk-dev] [PATCH v2 1/4] telemetry: use rte_log for logging
On Thu, Mar 25, 2021 at 03:09:32PM +0100, David Marchand wrote: > On Thu, Mar 25, 2021 at 2:57 PM Bruce Richardson > wrote: > > > > Rather than passing back an error string to the caller, take as input the > > rte_log function to use, and just use regular logging. > > > > Signed-off-by: Bruce Richardson > > Acked-by: Ciara Power > > I guess this replaces > http://patchwork.dpdk.org/project/dpdk/patch/20210308222339.819494-1-tho...@monjalon.net/ > ? Yes, it would do.
Re: [dpdk-dev] [PATCH v2 2/2] examples/vhost_blk: Check protocol features before getting inflight info
On 3/22/21 8:22 AM, Keiichi Watanabe wrote: > Avoid calling rte_vhost_get_vhost_ring_inflight() and > rte_vhost_get_vring_base_from_inflight() when > VHOST_USER_PROTOCOL_F_INFLIGHT_SHMFD is not set. > > Signed-off-by: Keiichi Watanabe > --- > examples/vhost_blk/vhost_blk.c | 23 ++- > 1 file changed, 18 insertions(+), 5 deletions(-) > Reviewed-by: Maxime Coquelin Thanks, Maxime
Re: [dpdk-dev] [PATCH dpdk-dev v3 2/2] mempool: use shared memzone for rte_mempool_ops
On Mon, May 4, 2020 at 9:42 AM Olivier Matz wrote: > > Hi, > > On Tue, Apr 28, 2020 at 09:22:37PM +0800, Tonghao Zhang wrote: > > On Mon, Apr 27, 2020 at 8:51 PM Tonghao Zhang > > wrote: > > > > > > On Mon, Apr 27, 2020 at 7:40 PM Thomas Monjalon > > > wrote: > > > > > > > > 27/04/2020 10:03, Tonghao Zhang: > > > > > On Fri, Apr 17, 2020 at 6:27 AM Thomas Monjalon > > > > > wrote: > > > > > > > > > > > > 13/04/2020 16:21, xiangxia.m@gmail.com: > > > > > > > The order of mempool initiation affects mempool index in the > > > > > > > rte_mempool_ops_table. For example, when building APPs with: > > > > > > > > > > > > > > $ gcc -lrte_mempool_bucket -lrte_mempool_ring ... > > > > > > > > > > > > > > The "bucket" mempool will be registered firstly, and its index > > > > > > > in table is 0 while the index of "ring" mempool is 1. DPDK > > > > > > > uses the mk/rte.app.mk to build APPs, and others, for example, > > > > > > > Open vSwitch, use the libdpdk.a or libdpdk.so to build it. > > > > > > > The mempool lib linked in dpdk and Open vSwitch is different. > > > > > > > > > > > > We are supposed to use pkg-config to link DPDK. > > > > > > Does the problem appear between a DPDK compiled with meson > > > > > > and an application linked with pkg-config information? > > > Hi Thomas, > > > The library mempool linked order can trigger that problem. but when > > > the library is loaded > > > dynamically, trigger that problem too. > > > as Olivier Matz said: > > > The fact that the ops index changes during mempool driver lifetime is > > > indeed frightening, especially knowning that this is a dynamic > > > registration that could happen at any moment in the life of the > > > application. > > > > > > the message in https://mails.dpdk.org/archives/dev/2020-March/159354.html > > Hi Thomas, > > For first patch, I guess we support a callback for other library, it > > make the codes much cleaner > > at eal layer. Otherwise, if we init for library, we may include their > > header file. > > There is a better solution ? > > To summarize my understanding of the issu encountered by Tonghao: > > Currently, it is not possible to call memzone_register() from an init > function (registered with RTE_INIT()). This is needed if we want to > store the list of registered mempool ops in a shared memory, available > from multiprocess. > > Tonghao's patch 1/2 solves this issue. I tried to find alternatives > to this approach, but none of them seems satisfying: > > - use RTE_PMD_REGISTER_VDEV() and rte_vdev_add_custom_scan() instead of > RTE_INIT() in the MEMPOOL_REGISTER_OPS() macro to delay the > initialization after eal_init(). This looks too complex (I made a POC > of it, it someone is interested). > > - synchronize mempool ops in shared memory when mempool_create() is > called in the primary: this would probably works most of the time, but > it is not a perfect solution as we cannot ensure that the primary > application will create a mempool before the secondary comes up. > > - introduce a mandatory call to rte_mempool_lib_init(): despite it's the > usual way to initialize libs, this will break compatibility. > > > > > > > If the problem really needs to be solved, > > > > > > the EAL patch (first of this series) needs to be discussed > > > > > > and reviewed carefully. I don't imagine it being done in 20.05. > > > > > > > OK, let's discuss it once 20.05 is out. > Any news on this topic? Is this issue still a problem? -- David Marchand
Re: [dpdk-dev] [PATCH v4] eal: fix create user mem map repeatedly when it exists
07/12/2020 12:08, wangyunjian:
> From: Yunjian Wang
>
> Currently, user mem maps will check if the newly mapped area is adjacent
> to any existing mapping, but will not check if the mapping is identical
> because it assumes that the API will never get called with the same
> mapping twice. This will result in duplicate entries in the user mem
> maps list.
>
> Fix it by also checking for duplicate mappings, and skipping them if
> they are found.
Sorry, that's still difficult to read,
and it is not clear what is the impact of the bug.
+Cc some english native speakers for help.
> Fixes: 0cbce3a167f1 ("vfio: skip DMA map failure if already mapped")
> Cc: sta...@dpdk.org
>
> Signed-off-by: Yunjian Wang
> Acked-by: Anatoly Burakov
Re: [dpdk-dev] [PATCH] eal: prefix telemetry initialization message
09/03/2021 15:03, Bruce Richardson: > On Tue, Mar 09, 2021 at 10:59:52AM +, Bruce Richardson wrote: > > On Mon, Mar 08, 2021 at 11:23:38PM +0100, Thomas Monjalon wrote: > > > If the telemetry library initialization has some issue, > > > the error message is returned in a string > > > (to avoid circular dependency with EAL log system). > > > > > > In order to make clear where the message comes from, > > > a prefix is added. > > > Before: EAL: message > > > After:EAL: telemetry: message > > > > > > Signed-off-by: Thomas Monjalon > > > --- > > Acked-by: Bruce Richardson > > By the way, I have a nearly completed patch for the telemetry library to > switch it to doing its own logging instead of passing back a string. It > does require a function pointer to rte_log to be passed to the init call, > but thereafter things are pretty normal in it and simplifies things. I'll > send it on as soon as it is ready. Thank you for the rework. This patch is now classified as "Superseded".
Re: [dpdk-dev] [Linuxarm] [PATCH V2 0/4] add Hisilicon kunpeng CPU support
25/03/2021 14:26, oulijun: > 在 2021/3/25 20:19, Thomas Monjalon 写道: > > 25/03/2021 12:17, oulijun: > >> Ruifeng has reviewed-by. Does anyone else have any comments? Is it > >> necessary to send the V2? > > > > v2 for what? There is a change? > > > No. no change. So why are you asking to send a v2? > >> 在 2021/3/25 17:07, Thomas Monjalon 写道: > >>> 25/03/2021 09:54, oulijun: > Hi, Thomas&&Ferruh > > Do I need to send a patchset? > >>> > >>> ??? > >>> What do you mean? > >>> > 在 2021/3/10 9:35, Lijun Ou 写道: > > This series add meson build for Hisilicon kunpeng CPU. > > > > Lijun Ou (4): > > config/arm: add Hisilicon kunpeng920 implementer > > config/arm: add Hisilicon kunpeng930 implementer > > config/arm: add kunpeng920 meson cross compile target > > config/arm: add kunpeng930 meson cross compile target
Re: [dpdk-dev] [PATCH v2] eal: fix race in ctrl thread creation
Hi Olivier,
> Thank you for reporting this problem and submitting the patch.
> I think the issue can be fixed without any loop, like in this
> patch. What do you think?
I think getting rid of the loop is an excellent idea. Good thinking.
Your version is much cleaner.
> + __atomic_store_n(¶ms->barrier_refcnt, 2, __ATOMIC_RELEASE);
I don't mean to nitpick but I don't think you need to use
__atomic_store_n to initialize the refcnt. Either way is fine of
course :)
Thanks.
Le jeu. 25 mars 2021 à 07:27, Olivier Matz a écrit :
>
> As reported by Luc, there is a race where the barrier is destroyed by
> one thread, while the other thread did not yet leave
> pthread_barrier_wait.
>
> This patch fixes the race condition by adding an atomic counter to
> ensure that the barrier is destroyed only it is not used by any thread.
>
> Fixes: 3a0d465d4c53 ("eal: fix use-after-free on control thread creation")
> Cc: jianfeng@intel.com
> Cc: sta...@dpdk.org
>
> Reported-by: Luc Pelletier
> Signed-off-by: David Marchand
> Signed-off-by: Olivier Matz
> ---
>
> Hi Luc,
>
> Thank you for reporting this problem and submitting the patch.
> I think the issue can be fixed without any loop, like in this
> patch. What do you think?
>
> Regards,
> Olivier
>
>
> lib/librte_eal/common/eal_common_thread.c | 38 +--
> 1 file changed, 21 insertions(+), 17 deletions(-)
>
> diff --git a/lib/librte_eal/common/eal_common_thread.c
> b/lib/librte_eal/common/eal_common_thread.c
> index 73a055902a..891f825e87 100644
> --- a/lib/librte_eal/common/eal_common_thread.c
> +++ b/lib/librte_eal/common/eal_common_thread.c
> @@ -170,11 +170,11 @@ struct rte_thread_ctrl_params {
> void *(*start_routine)(void *);
> void *arg;
> pthread_barrier_t configured;
> + unsigned int barrier_refcnt;
> };
>
> static void *ctrl_thread_init(void *arg)
> {
> - int ret;
> struct internal_config *internal_conf =
> eal_get_internal_configuration();
> rte_cpuset_t *cpuset = &internal_conf->ctrl_cpuset;
> @@ -184,8 +184,9 @@ static void *ctrl_thread_init(void *arg)
>
> __rte_thread_init(rte_lcore_id(), cpuset);
>
> - ret = pthread_barrier_wait(¶ms->configured);
> - if (ret == PTHREAD_BARRIER_SERIAL_THREAD) {
> + pthread_barrier_wait(¶ms->configured);
> + if (__atomic_sub_fetch(¶ms->barrier_refcnt, 1,
> + __ATOMIC_ACQ_REL) == 0) {
> pthread_barrier_destroy(¶ms->configured);
> free(params);
> }
> @@ -210,15 +211,17 @@ rte_ctrl_thread_create(pthread_t *thread, const char
> *name,
>
> params->start_routine = start_routine;
> params->arg = arg;
> -
> - pthread_barrier_init(¶ms->configured, NULL, 2);
> -
> - ret = pthread_create(thread, attr, ctrl_thread_init, (void *)params);
> + __atomic_store_n(¶ms->barrier_refcnt, 2, __ATOMIC_RELEASE);
> + ret = pthread_barrier_init(¶ms->configured, NULL, 2);
> if (ret != 0) {
> free(params);
> return -ret;
> }
>
> + ret = pthread_create(thread, attr, ctrl_thread_init, (void *)params);
> + if (ret != 0)
> + goto fail;
> +
> if (name != NULL) {
> ret = rte_thread_setname(*thread, name);
> if (ret < 0)
> @@ -227,25 +230,26 @@ rte_ctrl_thread_create(pthread_t *thread, const char
> *name,
> }
>
> ret = pthread_setaffinity_np(*thread, sizeof(*cpuset), cpuset);
> - if (ret)
> - goto fail;
> + if (ret != 0)
> + goto fail_cancel;
>
> - ret = pthread_barrier_wait(¶ms->configured);
> - if (ret == PTHREAD_BARRIER_SERIAL_THREAD) {
> + pthread_barrier_wait(¶ms->configured);
> + if (__atomic_sub_fetch(¶ms->barrier_refcnt, 1,
> + __ATOMIC_ACQ_REL) == 0) {
> pthread_barrier_destroy(¶ms->configured);
> free(params);
> }
>
> return 0;
>
> -fail:
> - if (PTHREAD_BARRIER_SERIAL_THREAD ==
> - pthread_barrier_wait(¶ms->configured)) {
> - pthread_barrier_destroy(¶ms->configured);
> - free(params);
> - }
> +fail_cancel:
> pthread_cancel(*thread);
> pthread_join(*thread, NULL);
> +
> +fail:
> + pthread_barrier_destroy(¶ms->configured);
> + free(params);
> +
> return -ret;
> }
>
> --
> 2.29.2
>
Re: [dpdk-dev] [PATCH] eal: changes for setting control thread mask
On Tue, Apr 21, 2020 at 10:01 AM David Marchand wrote: > > On Tue, Apr 21, 2020 at 9:42 AM Kiran KN wrote: > > Define a global variable ctrl_thread_set which the application can set. > > If this is the case, use this for setting control thread affinity instead > > of deducing it from the existing core pinning of the process. > > I am unconvinced on adding an EAL option for this. > It needs an explanation on why you can't rely on the dpdk process > current affinity for control threads. > And we will need a unit test. > > Please rebase your patch on master too. > > > signed-off-by: Kiran KN > > Signed-off-by* Is this patch abandoned? Thanks. -- David Marchand
[dpdk-dev] [PATCH 21.11 v2 0/3] octeontx build only on 64-bit Linux
This is a reorg of the patches from Pavan. It has been discussed that it should wait for DPDK 21.11 for ABI compatibility reason. Pavan Nikhilesh (3): net/thunderx: enable build only on 64-bit Linux common/octeontx: enable build only on 64-bit Linux common/octeontx2: enable build only on 64-bit Linux drivers/common/octeontx/meson.build | 6 ++ drivers/common/octeontx2/meson.build | 4 ++-- drivers/compress/octeontx/meson.build | 6 ++ drivers/crypto/octeontx/meson.build | 7 +-- drivers/event/octeontx/meson.build| 6 ++ drivers/event/octeontx2/meson.build | 4 ++-- drivers/mempool/octeontx/meson.build | 5 +++-- drivers/mempool/octeontx2/meson.build | 9 ++--- drivers/net/octeontx/meson.build | 4 ++-- drivers/net/octeontx2/meson.build | 10 ++ drivers/net/thunderx/meson.build | 4 ++-- drivers/raw/octeontx2_dma/meson.build | 10 ++ 12 files changed, 44 insertions(+), 31 deletions(-) -- 2.30.1
[dpdk-dev] [PATCH 21.11 v2 1/3] net/thunderx: enable build only on 64-bit Linux
From: Pavan Nikhilesh
Due to Linux kernel dependency, only enable build for 64-bit Linux.
Signed-off-by: Pavan Nikhilesh
Acked-by: Jerin Jacob
---
drivers/net/thunderx/meson.build | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/thunderx/meson.build b/drivers/net/thunderx/meson.build
index dad5c59242..97a84d5875 100644
--- a/drivers/net/thunderx/meson.build
+++ b/drivers/net/thunderx/meson.build
@@ -1,9 +1,9 @@
# SPDX-License-Identifier: BSD-3-Clause
# Copyright(c) 2017 Cavium, Inc
-if is_windows
+if not is_linux or not dpdk_conf.get('RTE_ARCH_64')
build = false
- reason = 'not supported on Windows'
+ reason = 'only supported on 64-bit Linux'
subdir_done()
endif
--
2.30.1
[dpdk-dev] [PATCH 21.11 v2 2/3] common/octeontx: enable build only on 64-bit Linux
From: Pavan Nikhilesh
Due to Linux kernel dependency, only enable build for 64-bit Linux.
Signed-off-by: Pavan Nikhilesh
Acked-by: Jerin Jacob
---
drivers/common/octeontx/meson.build | 6 ++
drivers/compress/octeontx/meson.build | 6 ++
drivers/crypto/octeontx/meson.build | 7 +--
drivers/event/octeontx/meson.build| 6 ++
drivers/mempool/octeontx/meson.build | 5 +++--
drivers/net/octeontx/meson.build | 4 ++--
6 files changed, 28 insertions(+), 6 deletions(-)
diff --git a/drivers/common/octeontx/meson.build
b/drivers/common/octeontx/meson.build
index 203d1ef496..f29b583204 100644
--- a/drivers/common/octeontx/meson.build
+++ b/drivers/common/octeontx/meson.build
@@ -2,4 +2,10 @@
# Copyright(c) 2018 Cavium, Inc
#
+if not is_linux or not dpdk_conf.get('RTE_ARCH_64')
+ build = false
+ reason = 'only supported on 64-bit Linux'
+ subdir_done()
+endif
+
sources = files('octeontx_mbox.c')
diff --git a/drivers/compress/octeontx/meson.build
b/drivers/compress/octeontx/meson.build
index e1b7bed422..cd8687fde3 100644
--- a/drivers/compress/octeontx/meson.build
+++ b/drivers/compress/octeontx/meson.build
@@ -1,6 +1,12 @@
# SPDX-License-Identifier: BSD-3-Clause
# Copyright(c) 2018 Cavium, Inc
+if not is_linux or not dpdk_conf.get('RTE_ARCH_64')
+ build = false
+ reason = 'only supported on 64-bit Linux'
+ subdir_done()
+endif
+
sources = files('otx_zip.c', 'otx_zip_pmd.c')
includes += include_directories('include')
deps += ['mempool_octeontx', 'bus_pci']
diff --git a/drivers/crypto/octeontx/meson.build
b/drivers/crypto/octeontx/meson.build
index a353d37a10..2e5838641d 100644
--- a/drivers/crypto/octeontx/meson.build
+++ b/drivers/crypto/octeontx/meson.build
@@ -1,8 +1,11 @@
# SPDX-License-Identifier: BSD-3-Clause
# Copyright(c) 2018 Cavium, Inc
-if not is_linux
+#
+
+if not is_linux or not dpdk_conf.get('RTE_ARCH_64')
build = false
- reason = 'only supported on Linux'
+ reason = 'only supported on 64-bit Linux'
+ subdir_done()
endif
deps += ['bus_pci']
diff --git a/drivers/event/octeontx/meson.build
b/drivers/event/octeontx/meson.build
index 41e367684c..63c7f793a6 100644
--- a/drivers/event/octeontx/meson.build
+++ b/drivers/event/octeontx/meson.build
@@ -1,6 +1,12 @@
# SPDX-License-Identifier: BSD-3-Clause
# Copyright(c) 2017 Cavium, Inc
+if not is_linux or not dpdk_conf.get('RTE_ARCH_64')
+ build = false
+ reason = 'only supported on 64-bit Linux'
+ subdir_done()
+endif
+
sources = files('ssovf_worker.c',
'ssovf_evdev.c',
'ssovf_evdev_selftest.c',
diff --git a/drivers/mempool/octeontx/meson.build
b/drivers/mempool/octeontx/meson.build
index b5695a9329..4607dfe23d 100644
--- a/drivers/mempool/octeontx/meson.build
+++ b/drivers/mempool/octeontx/meson.build
@@ -1,9 +1,10 @@
# SPDX-License-Identifier: BSD-3-Clause
# Copyright(c) 2017 Cavium, Inc
-if is_windows
+if not is_linux or not dpdk_conf.get('RTE_ARCH_64')
build = false
- reason = 'not supported on Windows'
+ reason = 'only supported on 64-bit Linux'
+ subdir_done()
endif
sources = files('octeontx_fpavf.c',
diff --git a/drivers/net/octeontx/meson.build b/drivers/net/octeontx/meson.build
index 4e784b9484..a0d0fb80e6 100644
--- a/drivers/net/octeontx/meson.build
+++ b/drivers/net/octeontx/meson.build
@@ -1,9 +1,9 @@
# SPDX-License-Identifier: BSD-3-Clause
# Copyright(c) 2017 Cavium, Inc
-if is_windows
+if not is_linux or not dpdk_conf.get('RTE_ARCH_64')
build = false
- reason = 'not supported on Windows'
+ reason = 'only supported on 64-bit Linux'
subdir_done()
endif
--
2.30.1
[dpdk-dev] [PATCH 21.11 v2 3/3] common/octeontx2: enable build only on 64-bit Linux
From: Pavan Nikhilesh
Due to Linux kernel dependency, only enable build for 64-bit Linux.
Signed-off-by: Pavan Nikhilesh
Acked-by: Jerin Jacob
---
drivers/common/octeontx2/meson.build | 4 ++--
drivers/event/octeontx2/meson.build | 4 ++--
drivers/mempool/octeontx2/meson.build | 9 ++---
drivers/net/octeontx2/meson.build | 10 ++
drivers/raw/octeontx2_dma/meson.build | 10 ++
5 files changed, 14 insertions(+), 23 deletions(-)
diff --git a/drivers/common/octeontx2/meson.build
b/drivers/common/octeontx2/meson.build
index 84fb11524d..3ae1067921 100644
--- a/drivers/common/octeontx2/meson.build
+++ b/drivers/common/octeontx2/meson.build
@@ -2,9 +2,9 @@
# Copyright(C) 2019 Marvell International Ltd.
#
-if not dpdk_conf.get('RTE_ARCH_64')
+if not is_linux or not dpdk_conf.get('RTE_ARCH_64')
build = false
- reason = 'only supported on 64-bit'
+ reason = 'only supported on 64-bit Linux'
subdir_done()
endif
diff --git a/drivers/event/octeontx2/meson.build
b/drivers/event/octeontx2/meson.build
index 22e7e4cb63..c81950cefe 100644
--- a/drivers/event/octeontx2/meson.build
+++ b/drivers/event/octeontx2/meson.build
@@ -2,9 +2,9 @@
# Copyright(C) 2019 Marvell International Ltd.
#
-if not dpdk_conf.get('RTE_ARCH_64')
+if not is_linux or not dpdk_conf.get('RTE_ARCH_64')
build = false
- reason = 'only supported on 64-bit'
+ reason = 'only supported on 64-bit Linux'
subdir_done()
endif
diff --git a/drivers/mempool/octeontx2/meson.build
b/drivers/mempool/octeontx2/meson.build
index 0586321abe..c67d8e2d20 100644
--- a/drivers/mempool/octeontx2/meson.build
+++ b/drivers/mempool/octeontx2/meson.build
@@ -2,14 +2,9 @@
# Copyright(C) 2019 Marvell International Ltd.
#
-if is_windows
+if not is_linux or not dpdk_conf.get('RTE_ARCH_64')
build = false
- reason = 'not supported on Windows'
- subdir_done()
-endif
-if not dpdk_conf.get('RTE_ARCH_64')
- build = false
- reason = 'only supported on 64-bit'
+ reason = 'only supported on 64-bit Linux'
subdir_done()
endif
diff --git a/drivers/net/octeontx2/meson.build
b/drivers/net/octeontx2/meson.build
index 779a75b5d0..5dbe002e3f 100644
--- a/drivers/net/octeontx2/meson.build
+++ b/drivers/net/octeontx2/meson.build
@@ -2,15 +2,9 @@
# Copyright(C) 2019 Marvell International Ltd.
#
-if is_windows
+if not is_linux or not dpdk_conf.get('RTE_ARCH_64')
build = false
- reason = 'not supported on Windows'
- subdir_done()
-endif
-
-if not dpdk_conf.get('RTE_ARCH_64')
- build = false
- reason = 'only supported on 64-bit'
+ reason = 'only supported on 64-bit Linux'
subdir_done()
endif
diff --git a/drivers/raw/octeontx2_dma/meson.build
b/drivers/raw/octeontx2_dma/meson.build
index 11f74680a5..1910351253 100644
--- a/drivers/raw/octeontx2_dma/meson.build
+++ b/drivers/raw/octeontx2_dma/meson.build
@@ -2,14 +2,16 @@
# Copyright(C) 2019 Marvell International Ltd.
#
+if not is_linux or not dpdk_conf.get('RTE_ARCH_64')
+ build = false
+ reason = 'only supported on 64-bit Linux'
+ subdir_done()
+endif
+
deps += ['bus_pci', 'common_octeontx2', 'rawdev']
sources = files('otx2_dpi_rawdev.c', 'otx2_dpi_msg.c', 'otx2_dpi_test.c')
extra_flags = []
-# This integrated controller runs only on a arm64 machine, remove 32bit
warnings
-if not dpdk_conf.get('RTE_ARCH_64')
- extra_flags += ['-Wno-int-to-pointer-cast', '-Wno-pointer-to-int-cast']
-endif
foreach flag: extra_flags
if cc.has_argument(flag)
--
2.30.1
Re: [dpdk-dev] [PATCH 1/7] common/octeontx: enable build only on 64bit Linux
25/03/2021 13:46, Jerin Jacob: > On Thu, Mar 25, 2021 at 4:33 PM Thomas Monjalon wrote: > > 25/03/2021 11:58, Kinsella, Ray: > > > On 25/03/2021 10:46, Thomas Monjalon wrote: > > > > 25/03/2021 11:42, Thomas Monjalon: > > > >> I've reorganized the commits per family of drivers, > > > >> so it makes more sense than grouping per driver class > > > >> with "common/octeontx" for title for all: > > > >> > > > >> net/thunderx: enable build only on 64-bit Linux > > > >> common/octeontx: enable build only on 64-bit Linux > > > >> common/octeontx2: enable build only on 64-bit Linux > > > >> > > > >> and applied. > > > > > > > > Actually not applied yet. > > > > I'm not sure what to do for the ABI check which is broken > > > > because some drivers are not compiled anymore in 32-bit build. > > > > I've workarounded locally by removing the dump files in the reference > > > > build. > > > > Should we add an exception in libabigail.abignore? > > > > > > > In the past we said that depreciating HW support would be considered to > > > be same as an ABI Breakage. > > > > > > From the policy ... > > > "Updates to the minimum hardware requirements, which drop support for > > > hardware which was previously supported, should be treated as an ABI > > > change." > > > > So the patches should wait 21.11. > > Everybody agree? > > Looks good to me to postpone. The v2 is waiting in patchwork with the status "Deferred": https://patches.dpdk.org/project/dpdk/list/?series=15885&state=*
Re: [dpdk-dev] [PATCH v2 0/2] Use WFE for spinlock and ring
Hello, On Fri, Sep 25, 2020 at 4:30 PM David Marchand wrote: > > Hello Honnappa, > > On Sun, May 3, 2020 at 11:32 PM Honnappa Nagarahalli > wrote: > > > > > > > > > Subject: Re: [PATCH v2 0/2] Use WFE for spinlock and ring > > > > > > On Sun, Apr 26, 2020 at 10:39 AM Gavin Hu wrote: > > > > > > > > The rte_wait_until_equal_xxx APIs abstract the functionality of > > > > 'polling for a memory location to become equal to a given value'[1]. > > > > > > > > Use the API for the rte spinlock and ring implementations. > > > > > > > > [1] http://patches.dpdk.org/cover/62703/ > > > > > > > > Gavin Hu (2): > > > > spinlock: use wfe to reduce contention on aarch64 > > > > ring: use wfe to wait for ring tail update on aarch64 > > > > > > This would result in rte_ring and rte_spinlock APIs becoming experimental > > > and this breaks compilation for external applications using stable ring > > > and > > > spinlock APIs. > > > IIRC, it was the reason why these patches were dropped with the > > > introduction > > > of the rte_wait_until_equal_* API. > > Agreed, the rte_ring new sync modes are resulting in different use cases > > for these APIs. We need to take a relook at the APIs. > > Will we reconsider this series now that the wait until equal is going stable? Any update? I suppose this would need some rebasing after the ring library changes. Thanks. -- David Marchand
Re: [dpdk-dev] [PATCH 1/7] common/octeontx: enable build only on 64bit Linux
On Thu, Mar 25, 2021 at 3:57 PM Thomas Monjalon wrote: > > > > In the past we said that depreciating HW support would be considered to > > > > be same as an ABI Breakage. > > > > > > > > From the policy ... > > > > "Updates to the minimum hardware requirements, which drop support for > > > > hardware which was previously supported, should be treated as an ABI > > > > change." > > > > > > So the patches should wait 21.11. > > > Everybody agree? > > > > Looks good to me to postpone. > > The v2 is waiting in patchwork with the status "Deferred": > https://patches.dpdk.org/project/dpdk/list/?series=15885&state=* We need a deprecation notice. -- David Marchand
Re: [dpdk-dev] [PATCH v4 0/4] add travis ci support for ppc64le
On Thu, Apr 2, 2020 at 7:13 PM David Wilder wrote: > > This patch series adds Travis gcc compilation jobs and unit testing > for ppc64le. Limitations for ppc64le are similar to arm64 (see commit > 31bb45bcfd). > > 1. Only gcc builds are supported on ppc64le. > 2. Hugepages are not available in the ppc64le Travis environment. > 3. Memory requirements are larger for ppc64le due to a higher >RTE_MAX_LCORE value. > > V2: Insures iova-mode is VA when --no-huge is selected. > Removed setting of --iova-mode=VA in test-null.sh. > V3: Refactor ppc64le changes on top of David Marchand's > Patch series: "Reorganise Travis jobs" > http://mails.dpdk.org/archives/dev/2020-February/158231.html > V4: Adding unit testing. > Updated eal/linux: patch to force PA mode when --huge-page is used. > This should be a more straightforward solution than my V3 patch. > > A Travis build with theses patches can be found here: > https://travis-ci.org/github/djlwilder/dpdk/builds/670214578 > David Wilder (4): > eal/linux: force iova-mode va with no-huge option > devtools: allow test-null.sh to run on ppc64le > ci: add travis ci support for native ppc64le > ci: enable unit test for ppc64le > Is this series still applicable? The changes on EAL did not get a review. -- David Marchand
Re: [dpdk-dev] [PATCH] test/autotest: checking for skipped or unsupported tests
On Tue, Jun 2, 2020 at 6:53 PM David Christensen
wrote:
>
> > - When running the dedault configuration of autotest of the make test
> >it'd take 900 seconds (15 minutes) for the script TIMEOUT and marks
> >Failed for a specific device test that is not supported on the
> >system under test.
> > - Adding the checking for those tests, print out as "Skipped [Not Run]"
> >quickly return and continue for next test
Fixes: da0af48a67a5 ("test: add skipped return result")
Cc: sta...@dpdk.org
> >
> > Signed-off-by: Thinh Tran
Reviewed-by: David Christensen
Applied, thanks.
--
David Marchand
Re: [dpdk-dev] [dpdk-stable] [PATCH] EAL: Called remove() of drivers for vdev and pci buses
On Sun, Oct 25, 2020 at 10:28 PM Muhammad Bilal wrote: > > On Tue, Oct 20, 2020 at 6:43 PM David Marchand > wrote: > > > > Hello, > Hi > > > > On Sat, Sep 12, 2020 at 9:53 PM Gaëtan Rivet wrote: > > > > > > On 08/07/20 17:03 +0500, Muhammad Bilal wrote: > > > > while using memif with app, the resources are not cleaned on exit, > > > > So an error occurred on running it second time. The cause of this > > > > problem > > > > is that remove() of memif driver is not called by rte_eal_cleanup() > > > > which > > > > is counterpart of probe() called from rte_eal_init(). This is a case for > > > > all other divers e.g pci, so to solve this problem I have added the > > > > functionality of calling remove() function of all the driver attached to > > > > devices on vdev and pci buses. > > > > > > > > > > Hi Muhammad, > > > > > > review inline. > > > > There were comments from Gaetan, waiting for a v2. > I am working on required changes, and will update it soon. Any update? Thanks. -- David Marchand
Re: [dpdk-dev] [PATCH v2] mem: fix cleanup when multi-process is disabled
On 3/24/2021 12:32 PM, Dmitry Kozlyuk wrote:
rte_eal_memory_detach() did not account for cases where multi-process
mode is disabled: --in-memory and --no-shconf. This resulted
in unmapping memory that had not been mapped, which caused errors:
EAL: Could not unmap memory: No error (Windows)
EAL: Cannot munmap(0x1d47f40, 0x7000): Invalid argument (Linux)
Confusing "No error" was caused by using errno instead of rte_errno
set by rte_mem_unmap().
Skip detaching memory altogether when --in-memory is specified.
Skip unmapping configuration when it's not shared.
Fix and add error handling to produce proper log messages.
Fixes: dfbc61a2f9a6 ("mem: detach memsegs on cleanup")
Cc: Anatoly Burakov
Reported-by: Jie Zhou
Suggested-by: David Marchand
Signed-off-by: Dmitry Kozlyuk
---
lib/librte_eal/common/eal_common_memory.c | 12 ++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/lib/librte_eal/common/eal_common_memory.c
b/lib/librte_eal/common/eal_common_memory.c
index 0e99986d3d..9495170c86 100644
--- a/lib/librte_eal/common/eal_common_memory.c
+++ b/lib/librte_eal/common/eal_common_memory.c
@@ -1006,10 +1006,15 @@ rte_extmem_detach(void *va_addr, size_t len)
int
rte_eal_memory_detach(void)
{
+ const struct internal_config *internal_conf =
+ eal_get_internal_configuration();
struct rte_mem_config *mcfg = rte_eal_get_configuration()->mem_config;
size_t page_sz = rte_mem_page_size();
unsigned int i;
+ if (internal_conf->in_memory == 1)
+ return 0;
+
rte_rwlock_write_lock(&mcfg->memory_hotplug_lock);
/* detach internal memory subsystem data first */
@@ -1032,7 +1037,7 @@ rte_eal_memory_detach(void)
if (!msl->external)
if (rte_mem_unmap(msl->base_va, msl->len) != 0)
RTE_LOG(ERR, EAL, "Could not unmap memory:
%s\n",
- strerror(errno));
+ rte_strerror(rte_errno));
/*
* we are detaching the fbarray rather than destroying because
@@ -1050,7 +1055,10 @@ rte_eal_memory_detach(void)
* config - we can't zero it out because it might still be referenced
* by other processes.
*/
- rte_mem_unmap(mcfg, RTE_ALIGN(sizeof(*mcfg), page_sz));
+ if (internal_conf->no_shconf == 0)
+ if (rte_mem_unmap(mcfg, RTE_ALIGN(sizeof(*mcfg), page_sz)) != 0)
+ RTE_LOG(ERR, EAL, "Could not unmap shared memory config:
%s\n",
+ rte_strerror(rte_errno));
rte_eal_get_configuration()->mem_config = NULL;
return 0;
Acked-by: Ranjit Menon
Re: [dpdk-dev] [PATCH v5 8/8] net/igc: refine debug build option
On 3/24/2021 8:31 PM, David Marchand wrote:
On Wed, Mar 24, 2021 at 8:27 PM Ferruh Yigit wrote:
On 3/23/2021 11:07 AM, Qi Zhang wrote:
1. replace RTE_LIBRTE_IGC_DEBUG_RX with RTE_ETHDEV_DEBUG_RX.
2. replace RTE_LIBRTE_IGC_DEBUG_TX whth RTE_ETHDEV_DEBUG_TX.
3. merge RTE_LIBRTE_ETHDEV_DEBUG into RTE_ETHDEV_DEBUG_TX
Signed-off-by: Qi Zhang
CI is reporting a build error [1], I don't reproduce the error and I assume it
is false positive but can you please check it?
Also cc'ed Zhaoyan & Aaron for the possible CI issue.
[1]
http://mails.dpdk.org/archives/test-report/2021-March/184153.html
Not sure what gcc+debug target is, but I guess it passes the old config item.
The compat stuff should be placed in rte_config.h (or something
similar to config/rte_compatibility_defines.h) and not in
lib/librte_ethdev/rte_ethdev.h.
To reproduce:
$ meson configure $HOME/builds/build-gcc-static/
-Dc_args="-DRTE_LIBRTE_ETHDEV_DEBUG=1"
$ ./devtools/test-meson-builds.sh
Thanks for the steps, I can reproduce it. The alias is not working because
'rte_ethdev.h' where the alias is defined is not included in this path.
Following update should fix it, what do you think?
diff --git a/drivers/net/e1000/base/meson.build
b/drivers/net/e1000/base/meson.build
index d13f693d3eb8..a9f92cbc4770 100644
--- a/drivers/net/e1000/base/meson.build
+++ b/drivers/net/e1000/base/meson.build
@@ -33,6 +33,6 @@ foreach flag: error_cflags
endforeach
base_lib = static_library('e1000_base', sources,
- dependencies: static_rte_eal,
+ dependencies: [static_rte_eal,static_rte_ethdev],
c_args: c_args)
base_objs = base_lib.extract_all_objects()
diff --git a/drivers/net/e1000/e1000_logs.h b/drivers/net/e1000/e1000_logs.h
index 86f546b0f9ed..210c3447c66c 100644
--- a/drivers/net/e1000/e1000_logs.h
+++ b/drivers/net/e1000/e1000_logs.h
@@ -7,6 +7,9 @@
#include
+/* included because of RTE_LIBRTE_ETHDEV_DEBUG alias */
+#include
+
extern int e1000_logtype_init;
#define PMD_INIT_LOG(level, fmt, args...) \
Re: [dpdk-dev] [PATCH] ci: remove aarch64 from Travis jobs
16/04/2020 13:00, Thomas Monjalon: > Travis is not reliable for native Arm and PPC: > https://travis-ci.community/t/disk-quota-exceeded-on-arm64/7619/6 > > In order to get reliable Travis reports, > the use of Arm machines is removed until Travis fixes it. > > Signed-off-by: Thomas Monjalon We managed without applying this patch. After one year passed, what is the situation today regarding Travis? Can we rely on Travis service? For which workload? Which architecture? Aaron, what do you recommend?
Re: [dpdk-dev] [PATCH v3 3/7] net/txgbe: update link setup process of backplane NICs
On 3/25/2021 10:19 AM, Ferruh Yigit wrote:
On 3/25/2021 5:51 AM, Jiawen Wu wrote:
Add device arguments to support runtime options.
And use these configuration to control the link setup flow, to adapt to
different NIC's construction. Use firmware version to control the impact
of firmware update. And fix some left bugs.
Signed-off-by: Jiawen Wu
<...>
+#define TXGBE_DEBUG_BP
+#ifdef TXGBE_DEBUG_BP
+#define BP_LOG(fmt, ...) \
+ RTE_LOG(CRIT, PMD, "[%lu.%lu]%s(%d): " fmt, \
+ usec_stamp() / 100, usec_stamp() % 100, \
+ __func__, __LINE__, ## __VA_ARGS__)
+#else
+#define BP_LOG(fmt, ...) do { } while (0)
+#endif
+
#endif /* _TXGBE_LOGS_H_ */
The 'BP_LOG' looks like used for developer debug prints, if so I suggest
removing them completely,
but if not can you please convert it dynamic logging, or using existing dynamic
logs 'txgbe_logtype_init', 'txgbe_logtype_driver'?
Also, 'usec_stamp()' seems returning 'uint64_t', if so shouldn't use '%l' since
that will fail on 32bit, instead please prefer 'PRIu64'.
Re: [dpdk-dev] [PATCH] net/vmxnet3: build on Windows
On 3/24/2021 6:32 PM, Yong Wang wrote: -Original Message- From: Dmitry Kozlyuk Date: Wednesday, March 24, 2021 at 10:50 AM To: Yong Wang Cc: Ferruh Yigit , "dev@dpdk.org" , Narcisa Ana Maria Vasile , Dmitry Malloy , Pallavi Kadam Subject: Re: [dpdk-dev] [PATCH] net/vmxnet3: build on Windows 2021-03-23 17:13 (UTC+), Yong Wang: > -Original Message- > From: Ferruh Yigit > Date: Tuesday, March 23, 2021 at 9:11 AM > To: Dmitry Kozlyuk , "dev@dpdk.org" , Yong Wang > Cc: Narcisa Ana Maria Vasile , Dmitry Malloy , Pallavi Kadam > Subject: Re: [dpdk-dev] [PATCH] net/vmxnet3: build on Windows > > On 2/21/2021 12:55 AM, Dmitry Kozlyuk wrote: > > Remove OS restriction and update release notes. > > > > Signed-off-by: Dmitry Kozlyuk > > Build looks good, but I wonder if anyone tested the driver on Windows. > > Yong, > > Do you have any plan to test the driver on Windows, should we wait your ack? > > Ferruh, > > Unfortunately I don't have any Windows setup to test this change. Do you know what kind of tests have been done for this change? For the record, I tested the following setup with Windows Server 2019 in QEMU (-device vmxnet3) before submitting the patch: [ping ] [ ] [ ping] [OS ] [dpdk-skeleton] [ OS] [virtio---]--sockets--[---vmxnet3 vmxnet3---]--sockets--[---virtio] [Debian VM] [ Windows VM ] [Debian VM] Debian VMs successfully ping'd each other with Windows forwarding. Thanks Dmitri for the testing results. It will be good if you can try some basic tcp/udp traffic as well. Acked-by: Yong Wang Applied to dpdk-next-net/main, thanks. Added the above test detail to commit log for record.
Re: [dpdk-dev] [PATCH] tailq: secondary process may not have all tailq available
On Thu, 25 Mar 2021 15:16:47 +0100 David Marchand wrote: > On Mon, Jan 18, 2021 at 6:55 AM Hemant Agrawal > wrote: > > On 1/14/2021 7:14 PM, David Marchand wrote: > > > On Thu, Jan 14, 2021 at 8:24 AM Hemant Agrawal > > > wrote: > > >> Secondary process may not have all the tailq available for > > >> mapping, so better to ignore the error. > > >> > > >> e.g. if the primary process is linked with N libs > > >> and secondary process is linked with less number of libs. > > >> > > >> dpdk-procinfo results into following error: > > >> EAL: Cannot initialize tailq: VMBUS_RESOURCE_LIST > > > For dpdk-procinfo to complain about vmbus, it means the bus driver has > > > been loaded in the secondary, but not in the primary. > > > Is this what you intend to do? > > > > > Yes. > > > > Typically the customer applications are built/linked with only limited > > number of bus, devices > > > > dpdk-procinfo is getting compiled with default list as part of dpdk > > build. so, if customer is trying to use the default dpdk-procinfo with > > their application - there will be differences. > > > > Is this a usecase that we support or we want to support? > Thanks. > > Primary and secondary process have to be built with same DPDK version and same configuration values.
Re: [dpdk-dev] [PATCH v3 7/7] doc: add txgbe backplane update in release notes
On 3/25/2021 5:51 AM, Jiawen Wu wrote: Declare updates related to device args for backplane NICs. Signed-off-by: Jiawen Wu --- doc/guides/rel_notes/release_21_05.rst | 1 + 1 file changed, 1 insertion(+) diff --git a/doc/guides/rel_notes/release_21_05.rst b/doc/guides/rel_notes/release_21_05.rst index 8e686cc62..732d9743c 100644 --- a/doc/guides/rel_notes/release_21_05.rst +++ b/doc/guides/rel_notes/release_21_05.rst @@ -89,6 +89,7 @@ New Features * **Updated Wangxun txgbe driver.** * Added support for txgbevf PMD. + * Support device arguments to handle AN training for backplane NICs. * **Updated the AF_XDP driver.** Can you please squash this patch with the patch that introduces the feature, instead of having a separate patch?
Re: [dpdk-dev] [PATCH] tailq: secondary process may not have all tailq available
On Thu, Mar 25, 2021 at 09:05:51AM -0700, Stephen Hemminger wrote: > On Thu, 25 Mar 2021 15:16:47 +0100 > David Marchand wrote: > > > On Mon, Jan 18, 2021 at 6:55 AM Hemant Agrawal > > wrote: > > > On 1/14/2021 7:14 PM, David Marchand wrote: > > > > On Thu, Jan 14, 2021 at 8:24 AM Hemant Agrawal > > > > wrote: > > > >> Secondary process may not have all the tailq available for > > > >> mapping, so better to ignore the error. > > > >> > > > >> e.g. if the primary process is linked with N libs > > > >> and secondary process is linked with less number of libs. > > > >> > > > >> dpdk-procinfo results into following error: > > > >> EAL: Cannot initialize tailq: VMBUS_RESOURCE_LIST > > > > For dpdk-procinfo to complain about vmbus, it means the bus driver has > > > > been loaded in the secondary, but not in the primary. > > > > Is this what you intend to do? > > > > > > > Yes. > > > > > > Typically the customer applications are built/linked with only limited > > > number of bus, devices > > > > > > dpdk-procinfo is getting compiled with default list as part of dpdk > > > build. so, if customer is trying to use the default dpdk-procinfo with > > > their application - there will be differences. > > > > > > > Is this a usecase that we support or we want to support? > > Thanks. > > > > > > Primary and secondary process have to be built with same DPDK version > and same configuration values. I'd like to see support for the information provided by proc-info also exposed via telemetry callbacks, which would give us an easier way for tooling to request and process this data. Relying on something using the multi-process model is always going to have potential issues. /Bruce
