Re: [dpdk-dev] Question Of binutils-avx512-check
20/05/2021 23:22, Liang Ma: > Hi All, >I try to build DPDK with debug build-type but the building process is >failed becuase of AVX512 code from librte-acl. The release build type >is fine. Hence, I dig a bit into the avx512 enabling logic of meson. > >I found the main logic is implemented inside binutils-avx512-check.sh. > >It looks the script focus on checking the compatiblity of tools-chain >instead of CPUID. My problem is current script will produce avx512 >code even I build dpdk on AMD platform. I understand the avx512 code >may not be used in runtime. I just wonder why we can not check the >cpuid as well ? The same binary can be run on multiple CPUs, so it makes no sense to check the compilation CPUID in generic compilation. For native build, why not. Anyway, your problem is at compilation, not runtime, right?
Re: [dpdk-dev] Question Of binutils-avx512-check
On Fri, May 21, 2021 at 09:04:06AM +0200, Thomas Monjalon wrote: > 20/05/2021 23:22, Liang Ma: > > Hi All, > >I try to build DPDK with debug build-type but the building process is > >failed becuase of AVX512 code from librte-acl. The release build type > >is fine. Hence, I dig a bit into the avx512 enabling logic of meson. > > > >I found the main logic is implemented inside binutils-avx512-check.sh. > > > >It looks the script focus on checking the compatiblity of tools-chain > >instead of CPUID. My problem is current script will produce avx512 > >code even I build dpdk on AMD platform. I understand the avx512 code > >may not be used in runtime. I just wonder why we can not check the > >cpuid as well ? > > The same binary can be run on multiple CPUs, > so it makes no sense to check the compilation CPUID in generic compilation. > For native build, why not. > > Anyway, your problem is at compilation, not runtime, right? Yes, the problem is at compilation. Given X86_64, gcc-6.30, Debug build always failed due to librte_acl AVX512 code. I hope there is a graceful switch allow developer disable avx512 in certain circumstance.
Re: [dpdk-dev] Question Of binutils-avx512-check
On Fri, May 21, 2021 at 08:56:50AM +0100, Liang Ma wrote: > On Fri, May 21, 2021 at 09:04:06AM +0200, Thomas Monjalon wrote: > > 20/05/2021 23:22, Liang Ma: > > > Hi All, > > >I try to build DPDK with debug build-type but the building process is > > >failed becuase of AVX512 code from librte-acl. The release build type > > >is fine. Hence, I dig a bit into the avx512 enabling logic of meson. > > > > > >I found the main logic is implemented inside binutils-avx512-check.sh. > > > > > >It looks the script focus on checking the compatiblity of tools-chain > > >instead of CPUID. My problem is current script will produce avx512 > > >code even I build dpdk on AMD platform. I understand the avx512 code > > >may not be used in runtime. I just wonder why we can not check the > > >cpuid as well ? > > > > The same binary can be run on multiple CPUs, > > so it makes no sense to check the compilation CPUID in generic compilation. > > For native build, why not. > > > > Anyway, your problem is at compilation, not runtime, right? > Yes, the problem is at compilation. > Given X86_64, gcc-6.30, Debug build always failed due > to librte_acl AVX512 code. I hope there is a graceful switch allow > developer disable avx512 in certain circumstance. Add ACL maintainer on CC. Sounds like there is a problem with the AVX512 support detection for acl library. Looking at the meson build code, other drivers, such as i40e, do their avx512 detection differently from ACL.
Re: [dpdk-dev] Question Of binutils-avx512-check
On Fri, May 21, 2021 at 09:19:53AM +0100, Bruce Richardson wrote: > On Fri, May 21, 2021 at 08:56:50AM +0100, Liang Ma wrote: > > On Fri, May 21, 2021 at 09:04:06AM +0200, Thomas Monjalon wrote: > > > 20/05/2021 23:22, Liang Ma: > > > > Hi All, > > > >I try to build DPDK with debug build-type but the building process > > > > is > > > >failed becuase of AVX512 code from librte-acl. The release build type > > > >is fine. Hence, I dig a bit into the avx512 enabling logic of meson. > > > > > > > >I found the main logic is implemented inside > > > > binutils-avx512-check.sh. > > > > > > > >It looks the script focus on checking the compatiblity of tools-chain > > > >instead of CPUID. My problem is current script will produce avx512 > > > >code even I build dpdk on AMD platform. I understand the avx512 code > > > >may not be used in runtime. I just wonder why we can not check the > > > >cpuid as well ? > > > > > > The same binary can be run on multiple CPUs, > > > so it makes no sense to check the compilation CPUID in generic > > > compilation. > > > For native build, why not. > > > > > > Anyway, your problem is at compilation, not runtime, right? > > Yes, the problem is at compilation. > > Given X86_64, gcc-6.30, Debug build always failed due > > to librte_acl AVX512 code. I hope there is a graceful switch allow > > developer disable avx512 in certain circumstance. > > Add ACL maintainer on CC. Sounds like there is a problem with the AVX512 > support detection for acl library. Looking at the meson build code, other > drivers, such as i40e, do their avx512 detection differently from ACL. there are 2 concerns here: 1. librte_acl specific issue cause the debug building failure with gcc 6.30. 2. More generic, if that's possible to have a graceful switch for avx512.(e.g. build option)
[dpdk-dev] [PATCH v2] doc: explain steps for improved code spell checking
The script build-dict.sh was added in DPDK 20.08. It generates a better dictionary for spell checking done via checkpatch. Signed-off-by: Thomas Monjalon --- v2: explain the default --- doc/guides/contributing/patches.rst | 15 +-- 1 file changed, 9 insertions(+), 6 deletions(-) diff --git a/doc/guides/contributing/patches.rst b/doc/guides/contributing/patches.rst index 6dbbd5f8d1..b9cc6e67ae 100644 --- a/doc/guides/contributing/patches.rst +++ b/doc/guides/contributing/patches.rst @@ -430,14 +430,17 @@ updating the Linux kernel sources. The path to the original Linux script must be set in the environment variable ``DPDK_CHECKPATCH_PATH``. -Spell checking of commonly misspelled words -can be enabled by downloading the codespell dictionary:: - - https://raw.githubusercontent.com/codespell-project/codespell/master/codespell_lib/data/dictionary.txt - -The path to the downloaded ``dictionary.txt`` must be set +Spell checking of commonly misspelled words is enabled +by default if installed in ``/usr/share/codespell/dictionary.txt``. +A different dictionary path can be specified in the environment variable ``DPDK_CHECKPATCH_CODESPELL``. +There is a DPDK script to build an adjusted dictionary +from the multiple codespell dictionaries:: + + git clone https://github.com/codespell-project/codespell.git + devtools/build-dict.sh codespell/ > codespell-dpdk.txt + Environment variables required by the development tools, are loaded from the following files, in order of preference:: -- 2.31.1
Re: [dpdk-dev] [dpdk-dev v2] maintainers: update for qat and ipsec-mb pmds
Hi Thomas, Will change in V3. Thanks. Regards, Fan > -Original Message- > From: Thomas Monjalon > Sent: Thursday, May 20, 2021 2:01 PM > To: Zhang, Roy Fan > Cc: dev@dpdk.org; gak...@marvell.com; Yigit, Ferruh > ; Doherty, Declan ; > Griffin, John ; Jain, Deepak K > ; Trahe, Fiona > Subject: Re: [dpdk-dev v2] maintainers: update for qat and ipsec-mb pmds > > 20/05/2021 14:16, Fan Zhang: > > Add myself to Crypto API, QAT, SW PMDs based on ipsec-mb, and > > NULL PMD maintainer. > > You should mention the removal as well. > > If you want to be a maintainer, please be more precise in your patch ;) > > [...] > > Crypto API > > -M: Declan Doherty > > +M: Fan Zhang > > It is not an update for PMDs only, the title is not accurate. >
Re: [dpdk-dev] [dpdk-dev v1] cperf: fix crypto perf out-of-place mempool alloc
> -Original Message-
> From: Ji, Kai
> Sent: Thursday, May 20, 2021 4:07 PM
> To: dev@dpdk.org
> Cc: Zhang, Roy Fan ; Ji, Kai ;
> De Lara Guarch, Pablo
> Subject: [dpdk-dev v1] cperf: fix crypto perf out-of-place mempool alloc
>
> Add in missing rte_mbuf size in mempool allocation for out-of-place op.
>
> Fixes: bf9d6702eca9 ("app/crypto-perf: use single mempool")
> Cc: pablo.de.lara.gua...@intel.com
>
> Signed-off-by: Kai Ji
> ---
> app/test-crypto-perf/cperf_test_common.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/app/test-crypto-perf/cperf_test_common.c b/app/test-crypto-
> perf/cperf_test_common.c
> index 058e0ba564..12925c7f22 100644
> --- a/app/test-crypto-perf/cperf_test_common.c
> +++ b/app/test-crypto-perf/cperf_test_common.c
> @@ -194,7 +194,7 @@ cperf_alloc_common_memory(const struct
> cperf_options *options,
> (mbuf_size * segments_nb);
> params.dst_buf_offset = *dst_buf_offset;
> /* Destination buffer will be one segment only */
> - obj_size += max_size;
> + obj_size += max_size + sizeof(struct rte_mbuf);
> }
>
> *pool = rte_mempool_create_empty(pool_name,
> --
> 2.17.1
Acked-by: Fan Zhang
[dpdk-dev] [PATCH v2] doc: improve lstopo tip
The tool lstopo from hwloc package can provide a graphical or textual view. In its textual form, the option --merge gives a shorter summary which fits well with the DPDK need. Signed-off-by: Thomas Monjalon --- v2: add textual output in Linux guide --- doc/guides/linux_gsg/build_sample_apps.rst | 13 + doc/guides/nics/mlx4.rst | 2 +- doc/guides/nics/mlx5.rst | 2 +- 3 files changed, 11 insertions(+), 6 deletions(-) diff --git a/doc/guides/linux_gsg/build_sample_apps.rst b/doc/guides/linux_gsg/build_sample_apps.rst index 78652549a7..709b301427 100644 --- a/doc/guides/linux_gsg/build_sample_apps.rst +++ b/doc/guides/linux_gsg/build_sample_apps.rst @@ -138,11 +138,16 @@ This can be useful when using other processors to understand the mapping of the .. note:: -A more graphical view of the logical core layout may be obtained using the ``lstopo`` Linux utility. -On Fedora Linux, this may be installed and run using the following command:: + A more graphical view of the logical core layout + may be obtained using the ``lstopo`` Linux utility. + On Fedora, this may be installed and run using the following commands:: -sudo yum install hwloc -./lstopo + sudo yum install hwloc + lstopo + + This command produces a quite short textual output:: + + lstopo-no-graphics --merge .. warning:: diff --git a/doc/guides/nics/mlx4.rst b/doc/guides/nics/mlx4.rst index 9742ddb268..a25add7c47 100644 --- a/doc/guides/nics/mlx4.rst +++ b/doc/guides/nics/mlx4.rst @@ -308,7 +308,7 @@ Performance tuning for better performance. For VMs, verify that the right CPU and NUMA node are pinned according to the above. Run:: -lstopo-no-graphics +lstopo-no-graphics --merge to identify the NUMA node to which the PCIe adapter is connected. diff --git a/doc/guides/nics/mlx5.rst b/doc/guides/nics/mlx5.rst index 220c6e505a..83299646dd 100644 --- a/doc/guides/nics/mlx5.rst +++ b/doc/guides/nics/mlx5.rst @@ -1496,7 +1496,7 @@ Performance tuning for better performance. For VMs, verify that the right CPU and NUMA node are pinned according to the above. Run:: -lstopo-no-graphics +lstopo-no-graphics --merge to identify the NUMA node to which the PCIe adapter is connected. -- 2.31.1
Re: [dpdk-dev] Question Of binutils-avx512-check
On Fri, May 21, 2021 at 09:55:37AM +0100, Liang Ma wrote: > On Fri, May 21, 2021 at 09:19:53AM +0100, Bruce Richardson wrote: > > On Fri, May 21, 2021 at 08:56:50AM +0100, Liang Ma wrote: > > > On Fri, May 21, 2021 at 09:04:06AM +0200, Thomas Monjalon wrote: > > > > 20/05/2021 23:22, Liang Ma: > > > > > Hi All, > > > > >I try to build DPDK with debug build-type but the building > > > > > process is > > > > >failed becuase of AVX512 code from librte-acl. The release build > > > > > type > > > > >is fine. Hence, I dig a bit into the avx512 enabling logic of > > > > > meson. > > > > > > > > > >I found the main logic is implemented inside > > > > > binutils-avx512-check.sh. > > > > > > > > > >It looks the script focus on checking the compatiblity of > > > > > tools-chain > > > > >instead of CPUID. My problem is current script will produce avx512 > > > > >code even I build dpdk on AMD platform. I understand the avx512 > > > > > code > > > > >may not be used in runtime. I just wonder why we can not check the > > > > >cpuid as well ? > > > > > > > > The same binary can be run on multiple CPUs, > > > > so it makes no sense to check the compilation CPUID in generic > > > > compilation. > > > > For native build, why not. > > > > > > > > Anyway, your problem is at compilation, not runtime, right? > > > Yes, the problem is at compilation. > > > Given X86_64, gcc-6.30, Debug build always failed due > > > to librte_acl AVX512 code. I hope there is a graceful switch allow > > > developer disable avx512 in certain circumstance. > > > > Add ACL maintainer on CC. Sounds like there is a problem with the AVX512 > > support detection for acl library. Looking at the meson build code, other > > drivers, such as i40e, do their avx512 detection differently from ACL. > there are 2 concerns here: > 1. librte_acl specific issue cause the debug building failure with gcc 6.30. +1. This needs to be investigated and fixed if it's causing problems. > 2. More generic, if that's possible to have a graceful switch for > avx512.(e.g. build option) Not sure why this is wanted because any AVX512 paths won't be used at runtime unless suitable for use. In any case, this should be already doable by passing -mno-avx512 flag in CFLAGS/c_args at config time.
[dpdk-dev] [PATCH v3 0/4] DLB2 fixes for 21.05
Just sending a series with 4 ordered fixes (versioned v3 since some were marked as v2). Fixed rebase damage, fixes lines and updated titles. -- David Marchand Timothy McDaniel (4): event/dlb2: remove references to deferred scheduling doc: fix runtime options in DLB2 guide event/dlb2: fix extraction of HW scheduling type event/dlb2: select scalar dequeue by default doc/guides/eventdevs/dlb2.rst | 54 +++--- drivers/event/dlb2/dlb2.c | 37 +++ drivers/event/dlb2/dlb2_priv.h | 9 ++ 3 files changed, 51 insertions(+), 49 deletions(-) -- 2.23.0
[dpdk-dev] [PATCH v3 1/4] event/dlb2: remove references to deferred scheduling
From: Timothy McDaniel
Deferred scheduling is a DLB v1.0 feature, and is not valid for
DLB v2.0 or v2.5.
Fixes: bc62748bd7d4 ("event/dlb2: add private data structures and constants")
Fixes: a2e4f1f5e79f ("event/dlb2: add dequeue and its burst variants")
Cc: sta...@dpdk.org
Signed-off-by: Timothy McDaniel
---
doc/guides/eventdevs/dlb2.rst | 21 -
drivers/event/dlb2/dlb2_priv.h | 3 ---
2 files changed, 24 deletions(-)
diff --git a/doc/guides/eventdevs/dlb2.rst b/doc/guides/eventdevs/dlb2.rst
index 31de6bc470..c60c454d6b 100644
--- a/doc/guides/eventdevs/dlb2.rst
+++ b/doc/guides/eventdevs/dlb2.rst
@@ -293,27 +293,6 @@ The PMD does not support the following configuration
sequences:
This sequence is not supported because the event device must be reconfigured
before its ports or queues can be.
-Deferred Scheduling
-~~~
-
-The DLB PMD's default behavior for managing a CQ is to "pop" the CQ once per
-dequeued event before returning from rte_event_dequeue_burst(). This frees the
-corresponding entries in the CQ, which enables the DLB to schedule more events
-to it.
-
-To support applications seeking finer-grained scheduling control -- for example
-deferring scheduling to get the best possible priority scheduling and
-load-balancing -- the PMD supports a deferred scheduling mode. In this mode,
-the CQ entry is not popped until the *subsequent* rte_event_dequeue_burst()
-call. This mode only applies to load-balanced event ports with dequeue depth of
-1.
-
-To enable deferred scheduling, use the defer_sched vdev argument like so:
-
-.. code-block:: console
-
- --vdev=dlb2_event,defer_sched=on
-
Atomic Inflights Allocation
~~~
diff --git a/drivers/event/dlb2/dlb2_priv.h b/drivers/event/dlb2/dlb2_priv.h
index 3140764a59..b1225af37e 100644
--- a/drivers/event/dlb2/dlb2_priv.h
+++ b/drivers/event/dlb2/dlb2_priv.h
@@ -32,7 +32,6 @@
#define DLB2_MAX_NUM_EVENTS "max_num_events"
#define DLB2_NUM_DIR_CREDITS "num_dir_credits"
#define DEV_ID_ARG "dev_id"
-#define DLB2_DEFER_SCHED_ARG "defer_sched"
#define DLB2_QID_DEPTH_THRESH_ARG "qid_depth_thresh"
#define DLB2_COS_ARG "cos"
#define DLB2_POLL_INTERVAL_ARG "poll_interval"
@@ -585,7 +584,6 @@ struct dlb2_eventdev {
uint16_t num_dir_ports; /* total num of dir ports requested */
bool umwait_allowed;
bool global_dequeue_wait; /* Not using per dequeue wait if true */
- bool defer_sched;
enum dlb2_cq_poll_modes poll_mode;
int poll_interval;
int sw_credit_quanta;
@@ -620,7 +618,6 @@ struct dlb2_devargs {
int max_num_events;
int num_dir_credits_override;
int dev_id;
- int defer_sched;
struct dlb2_qid_depth_thresholds qid_depth_thresholds;
enum dlb2_cos cos_id;
int poll_interval;
--
2.23.0
[dpdk-dev] [PATCH v3 2/4] doc: fix runtime options in DLB2 guide
From: Timothy McDaniel
Convert to PCI "--allow" devarg format.
The documentation was previously using the "--vdev" form, which cannot
be used with the DLB2 PF PMD.
Fixes: f3cad285bb88 ("event/dlb2: add infos get and configure")
Fixes: f7cc194b0f7e ("event/dlb2: add enqueue and its burst variants")
Fixes: a2e4f1f5e79f ("event/dlb2: add dequeue and its burst variants")
Fixes: 95aa7101cd3c ("doc: add some features to DLB2 guide")
Cc: sta...@dpdk.org
Signed-off-by: Timothy McDaniel
Signed-off-by: David Marchand
---
Changes since v2:
- updated title,
- fixed Fixes: lines,
- rebased with patch introducing vector option,
---
doc/guides/eventdevs/dlb2.rst | 20 ++--
1 file changed, 10 insertions(+), 10 deletions(-)
diff --git a/doc/guides/eventdevs/dlb2.rst b/doc/guides/eventdevs/dlb2.rst
index c60c454d6b..99ea8418a5 100644
--- a/doc/guides/eventdevs/dlb2.rst
+++ b/doc/guides/eventdevs/dlb2.rst
@@ -152,19 +152,19 @@ These pools' sizes are controlled by the nb_events_limit
field in struct
rte_event_dev_config. The load-balanced pool is sized to contain
nb_events_limit credits, and the directed pool is sized to contain
nb_events_limit/4 credits. The directed pool size can be overridden with the
-num_dir_credits vdev argument, like so:
+num_dir_credits devargs argument, like so:
.. code-block:: console
- --vdev=dlb2_event,num_dir_credits=
+ --allow ea:00.0,num_dir_credits=
This can be used if the default allocation is too low or too high for the
-specific application needs. The PMD also supports a vdev arg that limits the
+specific application needs. The PMD also supports a devarg that limits the
max_num_events reported by rte_event_dev_info_get():
.. code-block:: console
- --vdev=dlb2_event,max_num_events=
+ --allow ea:00.0,max_num_events=
By default, max_num_events is reported as the total available load-balanced
credits. If multiple DLB-based applications are being used, it may be desirable
@@ -315,11 +315,11 @@ buffer space (e.g. if not all queues are used, or aren't
used for atomic
scheduling).
The PMD provides a dev arg to override the default per-queue allocation. To
-increase a vdev's per-queue atomic-inflight allocation to (for example) 64:
+increase per-queue atomic-inflight allocation to (for example) 64:
.. code-block:: console
- --vdev=dlb2_event,atm_inflights=64
+ --allow ea:00.0,atm_inflights=64
QID Depth Threshold
~~~
@@ -342,9 +342,9 @@ shown below.
.. code-block:: console
- --vdev=dlb2_event,qid_depth_thresh=all:
- --vdev=dlb2_event,qid_depth_thresh=qidA-qidB:
- --vdev=dlb2_event,qid_depth_thresh=qid:
+ --allow ea:00.0,qid_depth_thresh=all:
+ --allow ea:00.0,qid_depth_thresh=qidA-qidB:
+ --allow ea:00.0,qid_depth_thresh=qid:
Class of service
@@ -366,4 +366,4 @@ Class of service can be specified in the devargs, as follows
.. code-block:: console
- --vdev=dlb2_event,cos=<0..4>
+ --allow ea:00.0,cos=<0..4>
--
2.23.0
[dpdk-dev] [PATCH v3 3/4] event/dlb2: fix extraction of HW scheduling type
From: Timothy McDaniel
The HW scheduling type was not being extracted properly
in the vector optimizaed dequeue path. It was also not
being recorded in the xstats.
Fixes: 000a7b8e7582 ("event/dlb2: optimize dequeue operation")
Signed-off-by: Timothy McDaniel
---
drivers/event/dlb2/dlb2.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/drivers/event/dlb2/dlb2.c b/drivers/event/dlb2/dlb2.c
index 5696f568cd..2a3e4ddb47 100644
--- a/drivers/event/dlb2/dlb2.c
+++ b/drivers/event/dlb2/dlb2.c
@@ -3561,6 +3561,11 @@ _process_deq_qes_vec_impl(struct dlb2_port *qm_port,
int ev_qid2 = qm_port->qid_mappings[hw_qid2];
int ev_qid3 = qm_port->qid_mappings[hw_qid3];
+ int hw_sched0 = _mm_extract_epi8(v_qe_meta, 3) & 3ul;
+ int hw_sched1 = _mm_extract_epi8(v_qe_meta, 7) & 3ul;
+ int hw_sched2 = _mm_extract_epi8(v_qe_meta, 11) & 3ul;
+ int hw_sched3 = _mm_extract_epi8(v_qe_meta, 15) & 3ul;
+
v_qid_done = _mm_insert_epi8(v_qid_done, ev_qid0, 2);
v_qid_done = _mm_insert_epi8(v_qid_done, ev_qid1, 6);
v_qid_done = _mm_insert_epi8(v_qid_done, ev_qid2, 10);
@@ -3682,19 +3687,27 @@ _process_deq_qes_vec_impl(struct dlb2_port *qm_port,
v_ev_3 = _mm_blend_epi16(v_unpk_ev_23, v_qe_3, 0x0F);
v_ev_3 = _mm_alignr_epi8(v_ev_3, v_ev_3, 8);
_mm_storeu_si128((__m128i *)&events[3], v_ev_3);
+ DLB2_INC_STAT(qm_port->ev_port->stats.rx_sched_cnt[hw_sched3],
+ 1);
/* fallthrough */
case 3:
v_ev_2 = _mm_unpacklo_epi64(v_unpk_ev_23, v_qe_2);
_mm_storeu_si128((__m128i *)&events[2], v_ev_2);
+ DLB2_INC_STAT(qm_port->ev_port->stats.rx_sched_cnt[hw_sched2],
+ 1);
/* fallthrough */
case 2:
v_ev_1 = _mm_blend_epi16(v_unpk_ev_01, v_qe_1, 0x0F);
v_ev_1 = _mm_alignr_epi8(v_ev_1, v_ev_1, 8);
_mm_storeu_si128((__m128i *)&events[1], v_ev_1);
+ DLB2_INC_STAT(qm_port->ev_port->stats.rx_sched_cnt[hw_sched1],
+ 1);
/* fallthrough */
case 1:
v_ev_0 = _mm_unpacklo_epi64(v_unpk_ev_01, v_qe_0);
_mm_storeu_si128((__m128i *)&events[0], v_ev_0);
+ DLB2_INC_STAT(qm_port->ev_port->stats.rx_sched_cnt[hw_sched0],
+ 1);
}
}
--
2.23.0
[dpdk-dev] [PATCH v3 4/4] event/dlb2: select scalar dequeue by default
From: Timothy McDaniel
Optimized dequeue using x86 vector instructions was added
in 21.05, but due to limited testing the default has been
changed back to the scalar mode implementation. The vector mode
implementation can be enabled via the devargs option
"vector_opts_enabled=".
Fixes: 000a7b8e7582 ("event/dlb2: optimize dequeue operation")
Signed-off-by: Timothy McDaniel
Signed-off-by: David Marchand
---
Changes since v2:
- updated title,
- rebased with doc patch,
---
doc/guides/eventdevs/dlb2.rst | 13 +
drivers/event/dlb2/dlb2.c | 24
drivers/event/dlb2/dlb2_priv.h | 6 +++---
3 files changed, 28 insertions(+), 15 deletions(-)
diff --git a/doc/guides/eventdevs/dlb2.rst b/doc/guides/eventdevs/dlb2.rst
index 99ea8418a5..bce984ca08 100644
--- a/doc/guides/eventdevs/dlb2.rst
+++ b/doc/guides/eventdevs/dlb2.rst
@@ -367,3 +367,16 @@ Class of service can be specified in the devargs, as
follows
.. code-block:: console
--allow ea:00.0,cos=<0..4>
+
+Use X86 Vector Instructions
+~~~
+
+DLB supports using x86 vector instructions to optimize the data path.
+
+The default mode of operation is to use scalar instructions, but
+the use of vector instructions can be enabled in the devargs, as
+follows
+
+.. code-block:: console
+
+ --allow ea:00.0,vector_opts_enabled=
diff --git a/drivers/event/dlb2/dlb2.c b/drivers/event/dlb2/dlb2.c
index 2a3e4ddb47..eca183753f 100644
--- a/drivers/event/dlb2/dlb2.c
+++ b/drivers/event/dlb2/dlb2.c
@@ -376,11 +376,11 @@ set_default_depth_thresh(const char *key __rte_unused,
}
static int
-set_vector_opts_disab(const char *key __rte_unused,
+set_vector_opts_enab(const char *key __rte_unused,
const char *value,
void *opaque)
{
- bool *dlb2_vector_opts_disabled = opaque;
+ bool *dlb2_vector_opts_enabled = opaque;
if (value == NULL || opaque == NULL) {
DLB2_LOG_ERR("NULL pointer\n");
@@ -388,9 +388,9 @@ set_vector_opts_disab(const char *key __rte_unused,
}
if ((*value == 'y') || (*value == 'Y'))
- *dlb2_vector_opts_disabled = true;
+ *dlb2_vector_opts_enabled = true;
else
- *dlb2_vector_opts_disabled = false;
+ *dlb2_vector_opts_enabled = false;
return 0;
}
@@ -1469,7 +1469,7 @@ dlb2_hw_create_ldb_port(struct dlb2_eventdev *dlb2,
#else
if ((qm_port->cq_depth > 64) ||
(!rte_is_power_of_2(qm_port->cq_depth)) ||
- (dlb2->vector_opts_disabled == true))
+ (dlb2->vector_opts_enabled == false))
qm_port->use_scalar = true;
#endif
@@ -1665,7 +1665,7 @@ dlb2_hw_create_dir_port(struct dlb2_eventdev *dlb2,
#else
if ((qm_port->cq_depth > 64) ||
(!rte_is_power_of_2(qm_port->cq_depth)) ||
- (dlb2->vector_opts_disabled == true))
+ (dlb2->vector_opts_enabled == false))
qm_port->use_scalar = true;
#endif
@@ -4434,7 +4434,7 @@ dlb2_primary_eventdev_probe(struct rte_eventdev *dev,
dlb2->poll_interval = dlb2_args->poll_interval;
dlb2->sw_credit_quanta = dlb2_args->sw_credit_quanta;
dlb2->default_depth_thresh = dlb2_args->default_depth_thresh;
- dlb2->vector_opts_disabled = dlb2_args->vector_opts_disabled;
+ dlb2->vector_opts_enabled = dlb2_args->vector_opts_enabled;
err = dlb2_iface_open(&dlb2->qm_instance, name);
if (err < 0) {
@@ -4538,7 +4538,7 @@ dlb2_parse_params(const char *params,
DLB2_POLL_INTERVAL_ARG,
DLB2_SW_CREDIT_QUANTA_ARG,
DLB2_DEPTH_THRESH_ARG,
-DLB2_VECTOR_OPTS_DISAB_ARG,
+DLB2_VECTOR_OPTS_ENAB_ARG,
NULL };
if (params != NULL && params[0] != '\0') {
@@ -4653,11 +4653,11 @@ dlb2_parse_params(const char *params,
}
ret = rte_kvargs_process(kvlist,
- DLB2_VECTOR_OPTS_DISAB_ARG,
- set_vector_opts_disab,
- &dlb2_args->vector_opts_disabled);
+ DLB2_VECTOR_OPTS_ENAB_ARG,
+ set_vector_opts_enab,
+ &dlb2_args->vector_opts_enabled);
if (ret != 0) {
- DLB2_LOG_ERR("%s: Error parsing vector opts
disabled",
+ DLB2_LOG_ERR("%s: Error parsing vector opts
enabled",
name);
rte_kvargs_free(kvlist);
return ret;
diff --git a/drivers/event/dlb2/dlb2_priv.h b/dr
Re: [dpdk-dev] [PATCH v2] doc: explain steps for improved code spell checking
On Fri, May 21, 2021 at 10:58 AM Thomas Monjalon wrote: > > The script build-dict.sh was added in DPDK 20.08. > It generates a better dictionary for spell checking > done via checkpatch. > > Signed-off-by: Thomas Monjalon Reviewed-by: David Marchand -- David Marchand
[dpdk-dev] [dpdk-dev v3] maintainers: update for crypto api/crypto perf/sw crypto pmds using ipsec-mb
Add myself as Crypto API, QAT, SW PMDs based on ipsec-mb, NULL PMD, and crypto perf test maintainer. Also remove Declan, Deepak, and John from the maintainers of these areas. Signed-off-by: Fan Zhang Acked-by: Declan Doherty Acked-by: Fiona Trahe Acked-by: John Griffin --- MAINTAINERS | 19 ++- 1 file changed, 10 insertions(+), 9 deletions(-) diff --git a/MAINTAINERS b/MAINTAINERS index 5877a16971..131a7aba73 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -421,7 +421,7 @@ F: examples/bbdev_app/ F: doc/guides/sample_app_ug/bbdev_app.rst Crypto API -M: Declan Doherty +M: Fan Zhang T: git://dpdk.org/next/dpdk-next-crypto F: lib/cryptodev/ F: app/test/test_cryptodev* @@ -429,7 +429,7 @@ F: examples/l2fwd-crypto/ Security API M: Akhil Goyal -M: Declan Doherty +M: Fan Zhang T: git://dpdk.org/next/dpdk-next-crypto F: lib/security/ F: doc/guides/prog_guide/rte_security.rst @@ -1031,23 +1031,22 @@ F: drivers/crypto/scheduler/ F: doc/guides/cryptodevs/scheduler.rst Intel AES-NI GCM -M: Declan Doherty M: Pablo de Lara +M: Fan Zhang F: drivers/crypto/aesni_gcm/ F: doc/guides/cryptodevs/aesni_gcm.rst F: doc/guides/cryptodevs/features/aesni_gcm.ini Intel AES-NI Multi-Buffer -M: Declan Doherty M: Pablo de Lara +M: Fan Zhang F: drivers/crypto/aesni_mb/ F: doc/guides/cryptodevs/aesni_mb.rst F: doc/guides/cryptodevs/features/aesni_mb.ini Intel QuickAssist -M: John Griffin M: Fiona Trahe -M: Deepak Kumar Jain +M: Fan Zhang F: drivers/crypto/qat/ F: drivers/common/qat/ F: doc/guides/cryptodevs/qat.rst @@ -1055,6 +1054,7 @@ F: doc/guides/cryptodevs/features/qat.ini KASUMI M: Pablo de Lara +M: Fan Zhang F: drivers/crypto/kasumi/ F: doc/guides/cryptodevs/kasumi.rst F: doc/guides/cryptodevs/features/kasumi.ini @@ -1081,7 +1081,7 @@ F: doc/guides/cryptodevs/octeontx2.rst F: doc/guides/cryptodevs/features/octeontx2.ini Null Crypto -M: Declan Doherty +M: Fan Zhang F: drivers/crypto/null/ F: doc/guides/cryptodevs/null.rst F: doc/guides/cryptodevs/features/null.ini @@ -1108,13 +1108,14 @@ F: doc/guides/cryptodevs/dpaa2_sec.rst F: doc/guides/cryptodevs/features/dpaa2_sec.ini OpenSSL -M: Declan Doherty +M: Fan Zhang F: drivers/crypto/openssl/ F: doc/guides/cryptodevs/openssl.rst F: doc/guides/cryptodevs/features/openssl.ini SNOW 3G M: Pablo de Lara +M: Fan Zhang F: drivers/crypto/snow3g/ F: doc/guides/cryptodevs/snow3g.rst F: doc/guides/cryptodevs/features/snow3g.ini @@ -1127,6 +1128,7 @@ F: doc/guides/cryptodevs/features/virtio.ini ZUC M: Pablo de Lara +M: Fan Zhang F: drivers/crypto/zuc/ F: doc/guides/cryptodevs/zuc.rst F: doc/guides/cryptodevs/features/zuc.ini @@ -1616,7 +1618,6 @@ F: app/test-compress-perf/ F: doc/guides/tools/comp_perf.rst Crypto performance test application -M: Declan Doherty M: Ciara Power T: git://dpdk.org/next/dpdk-next-crypto F: app/test-crypto-perf/ -- 2.25.1
Re: [dpdk-dev] [dpdk-announce] release candidate 21.05-rc4
All, Update the test status for Intel part. Till now dpdk21.05-rc4 test is almost finished and no new issue is found. # Basic Intel(R) NIC testing * Build or compile: *Build: cover the build test combination with latest GCC/Clang/ICC version and the popular OS revision such as Ubuntu20.04, CentOS Stream 8, etc. - All passed. - Bug about "crypto_zuc build failed on Fedora34 with gcc 11" has been fixed in RC4. *Compile: cover the CFLAGES(O0/O1/O2/O3) with popular OS such as Ubuntu20.04 and CentOS Stream 8. - All passed. * PF(i40e, ixgbe and igb): test scenarios including RTE_FLOW/TSO/Jumboframe/checksum offload/VLAN/VXLAN, etc. - All tests are done, no new issue is found except known issue. - 1 bug is reported based on rc1 in bugzilla. Patch has provided but need other patch supports, all of them will be fixed in next release. > * https://bugs.dpdk.org/show_bug.cgi?id=687 * VF(i40e, ixgbe and igb): test scenarios including VF-RTE_FLOW/TSO/Jumboframe/checksum offload/VLAN/VXLAN, etc. - All tests are done. No new issue is found except known issue. * PF/VF(ICE): test scenarios including /Switch features/Package Management/Flow Director/Advanced Tx/Advanced RSS/ACL/DCF/Share code update/Flexible Descriptor, etc. - All tests are done. No new issue is found except known issues. * Intel NIC single core/NIC performance: test scenarios including PF/VF single core performance test, RFC2544 Zero packet loss performance test, etc. - Test important part. No new issue is found. * Power and IPsec: * Power: test scenarios including bi-direction/Telemetry/Empty Poll Lib/Priority Base Frequency and so on. - All passed. No new issue is found. * IPsec: test scenarios including ipsec/ipsec-secgw - Not tested in RC4. Tested in RC1~RC3, no issue is found. # Basic cryptodev and virtio testing * Virtio: both function and performance test are covered. Such as PVP/Virtio_loopback/virtio-user loopback/virtio-net VM2VM perf testing/VMAWARE ESXI 7.0u2, etc. - All tests are done. - No new issue is found except known issues which are found in rc2. - Bug https://bugs.dpdk.org/show_bug.cgi?id=699 has been fixed in RC4. * Cryptodev: *Function test: test scenarios including Cryptodev API testing/CompressDev ISA-L/QAT/ZLIB PMD Testing/FIPS, etc. - All tests are done. No new bug is found except known issue. *Performance test: test scenarios including Thoughput Performance /Cryptodev Latency, etc. - All tests are done. Best regards, Yu Jiang >-Original Message- >From: dev On Behalf Of Thomas Monjalon >Sent: Thursday, May 20, 2021 5:47 AM >To: annou...@dpdk.org >Subject: [dpdk-dev] [dpdk-announce] release candidate 21.05-rc4 > >A new DPDK release candidate is ready for testing: > https://git.dpdk.org/dpdk/tag/?id=v21.05-rc4 > >There are only 48 new patches in this snapshot, meaning this release cycle is >almost closed. > >Release notes: > https://doc.dpdk.org/guides/rel_notes/release_21_05.html > >Please test and report issues on bugs.dpdk.org. >You may share some release validation results by replying to this message at >dev@dpdk.org. > >If no issue, DPDK 21.05 should be released at the end of this week. > >Please think about sharing your roadmap for DPDK 21.08. > >Thank you everyone >
Re: [dpdk-dev] Question Of binutils-avx512-check
> On Fri, May 21, 2021 at 09:19:53AM +0100, Bruce Richardson wrote: > > On Fri, May 21, 2021 at 08:56:50AM +0100, Liang Ma wrote: > > > On Fri, May 21, 2021 at 09:04:06AM +0200, Thomas Monjalon wrote: > > > > 20/05/2021 23:22, Liang Ma: > > > > > Hi All, > > > > >I try to build DPDK with debug build-type but the building > > > > > process is > > > > >failed becuase of AVX512 code from librte-acl. The release build > > > > > type > > > > >is fine. Hence, I dig a bit into the avx512 enabling logic of > > > > > meson. > > > > > > > > > >I found the main logic is implemented inside > > > > > binutils-avx512-check.sh. > > > > > > > > > >It looks the script focus on checking the compatiblity of > > > > > tools-chain > > > > >instead of CPUID. My problem is current script will produce avx512 > > > > >code even I build dpdk on AMD platform. I understand the avx512 > > > > > code > > > > >may not be used in runtime. I just wonder why we can not check the > > > > >cpuid as well ? > > > > > > > > The same binary can be run on multiple CPUs, > > > > so it makes no sense to check the compilation CPUID in generic > > > > compilation. > > > > For native build, why not. > > > > > > > > Anyway, your problem is at compilation, not runtime, right? > > > Yes, the problem is at compilation. > > > Given X86_64, gcc-6.30, Debug build always failed due > > > to librte_acl AVX512 code. I hope there is a graceful switch allow > > > developer disable avx512 in certain circumstance. > > > > Add ACL maintainer on CC. Sounds like there is a problem with the AVX512 > > support detection for acl library. Looking at the meson build code, other > > drivers, such as i40e, do their avx512 detection differently from ACL. If you feel something is wrong in particular, please let me know. > there are 2 concerns here: > 1. librte_acl specific issue cause the debug building failure with gcc 6.30. gcc 6.3 is pretty rare these days, but I'll try to find one to reproduce the issue. Meanwhile can you follow the procedure - open a new ticket in bugzilla, and provide more info: command to reproduce, particular error output, etc. > 2. More generic, if that's possible to have a graceful switch for > avx512.(e.g. build option) I don't see much point in that. avx512 code-path wouldn't be used at run-time if your box doesn't support it.
Re: [dpdk-dev] Question Of binutils-avx512-check
On Fri, May 21, 2021 at 10:07:07AM +0100, Bruce Richardson wrote: > On Fri, May 21, 2021 at 09:55:37AM +0100, Liang Ma wrote: > > On Fri, May 21, 2021 at 09:19:53AM +0100, Bruce Richardson wrote: > > > On Fri, May 21, 2021 at 08:56:50AM +0100, Liang Ma wrote: > > > > On Fri, May 21, 2021 at 09:04:06AM +0200, Thomas Monjalon wrote: > > > > > 20/05/2021 23:22, Liang Ma: > > > > > > Hi All, > > > > > >I try to build DPDK with debug build-type but the building > > > > > > process is > > > > > >failed becuase of AVX512 code from librte-acl. The release build > > > > > > type > > > > > >is fine. Hence, I dig a bit into the avx512 enabling logic of > > > > > > meson. > > > > > > > > > > > >I found the main logic is implemented inside > > > > > > binutils-avx512-check.sh. > > > > > > > > > > > >It looks the script focus on checking the compatiblity of > > > > > > tools-chain > > > > > >instead of CPUID. My problem is current script will produce > > > > > > avx512 > > > > > >code even I build dpdk on AMD platform. I understand the avx512 > > > > > > code > > > > > >may not be used in runtime. I just wonder why we can not check > > > > > > the > > > > > >cpuid as well ? > > > > > > > > > > The same binary can be run on multiple CPUs, > > > > > so it makes no sense to check the compilation CPUID in generic > > > > > compilation. > > > > > For native build, why not. > > > > > > > > > > Anyway, your problem is at compilation, not runtime, right? > > > > Yes, the problem is at compilation. > > > > Given X86_64, gcc-6.30, Debug build always failed due > > > > to librte_acl AVX512 code. I hope there is a graceful switch allow > > > > developer disable avx512 in certain circumstance. > > > > > > Add ACL maintainer on CC. Sounds like there is a problem with the AVX512 > > > support detection for acl library. Looking at the meson build code, other > > > drivers, such as i40e, do their avx512 detection differently from ACL. > > there are 2 concerns here: > > 1. librte_acl specific issue cause the debug building failure with gcc 6.30. > +1. This needs to be investigated and fixed if it's causing problems. > > > 2. More generic, if that's possible to have a graceful switch for > > avx512.(e.g. build option) > Not sure why this is wanted because any AVX512 paths won't be used at > runtime unless suitable for use. In any case, this should be already doable > by passing -mno-avx512 flag in CFLAGS/c_args at config time. sure, that works, I use that method this moment. It's nice to have a explicit way, because I use 30 mins to figure out that way. ;-)
Re: [dpdk-dev] Question Of binutils-avx512-check
On Fri, May 21, 2021 at 09:52:30AM +, Ananyev, Konstantin wrote: > > > > On Fri, May 21, 2021 at 09:19:53AM +0100, Bruce Richardson wrote: > > > On Fri, May 21, 2021 at 08:56:50AM +0100, Liang Ma wrote: > > > > On Fri, May 21, 2021 at 09:04:06AM +0200, Thomas Monjalon wrote: > > > > > 20/05/2021 23:22, Liang Ma: > > > > > > Hi All, > > > > > >I try to build DPDK with debug build-type but the building > > > > > > process is > > > > > >failed becuase of AVX512 code from librte-acl. The release build > > > > > > type > > > > > >is fine. Hence, I dig a bit into the avx512 enabling logic of > > > > > > meson. > > > > > > > > > > > >I found the main logic is implemented inside > > > > > > binutils-avx512-check.sh. > > > > > > > > > > > >It looks the script focus on checking the compatiblity of > > > > > > tools-chain > > > > > >instead of CPUID. My problem is current script will produce > > > > > > avx512 > > > > > >code even I build dpdk on AMD platform. I understand the avx512 > > > > > > code > > > > > >may not be used in runtime. I just wonder why we can not check > > > > > > the > > > > > >cpuid as well ? > > > > > > > > > > The same binary can be run on multiple CPUs, > > > > > so it makes no sense to check the compilation CPUID in generic > > > > > compilation. > > > > > For native build, why not. > > > > > > > > > > Anyway, your problem is at compilation, not runtime, right? > > > > Yes, the problem is at compilation. > > > > Given X86_64, gcc-6.30, Debug build always failed due > > > > to librte_acl AVX512 code. I hope there is a graceful switch allow > > > > developer disable avx512 in certain circumstance. > > > > > > Add ACL maintainer on CC. Sounds like there is a problem with the AVX512 > > > support detection for acl library. Looking at the meson build code, other > > > drivers, such as i40e, do their avx512 detection differently from ACL. > > If you feel something is wrong in particular, please let me know. > > > there are 2 concerns here: > > 1. librte_acl specific issue cause the debug building failure with gcc 6.30. > > gcc 6.3 is pretty rare these days, but I'll try to find one to reproduce the > issue. > Meanwhile can you follow the procedure - open a new ticket in bugzilla, > and provide more info: command to reproduce, particular error output, etc. Many thanks! I will log it in bugzilla. > > > 2. More generic, if that's possible to have a graceful switch for > > avx512.(e.g. build option) > > I don't see much point in that. > avx512 code-path wouldn't be used at run-time if your box doesn't support it. sure, I understand the code path will not be touched at run-time. but put it this way, what's the point to include this code in binary, if I know the box not support it. It's nice to have a knob :-).
[dpdk-dev] [Bug 717] Debug building failed due to librte_acl avx512 code
https://bugs.dpdk.org/show_bug.cgi?id=717 Bug ID: 717 Summary: Debug building failed due to librte_acl avx512 code Product: DPDK Version: 20.11 Hardware: x86 OS: Linux Status: UNCONFIRMED Severity: critical Priority: Normal Component: meson Assignee: dev@dpdk.org Reporter: lian...@liangbit.com Target Milestone: --- Platform X86_64 Compiler Gcc 6.30 Distro. Debian 9 run command like meson setup build --buildtype=debug then kick off ninja build. following is the failure log: [171/2456] Compiling C object lib/librte_acl/libavx512_tmp.a.p/acl_run_avx512.c.o FAILED: lib/librte_acl/libavx512_tmp.a.p/acl_run_avx512.c.o cc -Ilib/librte_acl/libavx512_tmp.a.p -Ilib/librte_acl -I../lib/librte_acl -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 -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 -DCC_AVX2_SUPPORT -mavx512f -mavx512vl -mavx512cd -mavx512bw -MD -MQ lib/librte_acl/libavx512_tmp.a.p/acl_run_avx512.c.o -MF lib/librte_acl/libavx512_tmp.a.p/acl_run_avx512.c.o.d -o lib/librte_acl/libavx512_tmp.a.p/acl_run_avx512.c.o -c ../lib/librte_acl/acl_run_avx512.c In file included from /usr/lib/gcc/x86_64-linux-gnu/6/include/immintrin.h:45:0, from /usr/lib/gcc/x86_64-linux-gnu/6/include/x86intrin.h:48, from ../lib/librte_eal/x86/include/rte_vect.h:31, from ../lib/librte_acl/rte_acl_osdep.h:33, from ../lib/librte_acl/rte_acl.h:14, from ../lib/librte_acl/acl_run.h:8, from ../lib/librte_acl/acl_run_sse.h:5, from ../lib/librte_acl/acl_run_avx512.c:5: ../lib/librte_acl/acl_run_avx512_common.h: In function ‘resolve_match_idx_avx512x16’: ../lib/librte_acl/acl_run_avx512x16.h:33:18: error: the last argument must be an 8-bit immediate #define _M_I_(x) _mm512_##x ^ ../lib/librte_acl/acl_run_avx512_common.h:373:9: note: in expansion of macro ‘_M_I_’ return _M_I_(slli_epi32)(mi, match_log); ^ [180/2456] Generating ethdev.sym_chk with a custom command (wrapped by meson to capture output) ninja: build stopped: subcommand failed. -- You are receiving this mail because: You are the assignee for the bug.
Re: [dpdk-dev] [PATCH v3 0/4] DLB2 fixes for 21.05
On 5/21/2021 10:11 AM, David Marchand wrote: > Just sending a series with 4 ordered fixes (versioned v3 since some were > marked as v2). > Fixed rebase damage, fixes lines and updated titles. > Thanks David!
Re: [dpdk-dev] [dpdk-dev v3] maintainers: update for crypto api/crypto perf/sw crypto pmds using ipsec-mb
> -Original Message- > From: dev On Behalf Of Fan Zhang > Sent: Friday, May 21, 2021 10:24 AM > To: dev@dpdk.org > Cc: tho...@monjalon.net; gak...@marvell.com; Yigit, Ferruh > ; Doherty, Declan ; Griffin, > John ; Jain, Deepak K ; > Trahe, Fiona ; Zhang, Roy Fan > > Subject: [dpdk-dev] [dpdk-dev v3] maintainers: update for crypto api/crypto > perf/sw crypto pmds using ipsec-mb > > Add myself as Crypto API, QAT, SW PMDs based on ipsec-mb, NULL PMD, and > crypto perf test maintainer. Also remove Declan, Deepak, and John from the > maintainers of these areas. > > Signed-off-by: Fan Zhang > Acked-by: Declan Doherty > Acked-by: Fiona Trahe > Acked-by: John Griffin Acked-by: Pablo de Lara
Re: [dpdk-dev] [dpdk-dev v1] cperf: fix crypto perf out-of-place mempool alloc
> -Original Message-
> From: Zhang, Roy Fan
> Sent: Friday, May 21, 2021 10:05 AM
> To: Ji, Kai ; dev@dpdk.org
> Cc: De Lara Guarch, Pablo
> Subject: RE: [dpdk-dev v1] cperf: fix crypto perf out-of-place mempool alloc
>
> > -Original Message-
> > From: Ji, Kai
> > Sent: Thursday, May 20, 2021 4:07 PM
> > To: dev@dpdk.org
> > Cc: Zhang, Roy Fan ; Ji, Kai
> > ; De Lara Guarch, Pablo
> >
> > Subject: [dpdk-dev v1] cperf: fix crypto perf out-of-place mempool
> > alloc
> >
> > Add in missing rte_mbuf size in mempool allocation for out-of-place op.
> >
> > Fixes: bf9d6702eca9 ("app/crypto-perf: use single mempool")
> > Cc: pablo.de.lara.gua...@intel.com
> >
> > Signed-off-by: Kai Ji
> > ---
> > app/test-crypto-perf/cperf_test_common.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/app/test-crypto-perf/cperf_test_common.c
> > b/app/test-crypto- perf/cperf_test_common.c index
> > 058e0ba564..12925c7f22 100644
> > --- a/app/test-crypto-perf/cperf_test_common.c
> > +++ b/app/test-crypto-perf/cperf_test_common.c
> > @@ -194,7 +194,7 @@ cperf_alloc_common_memory(const struct
> > cperf_options *options,
> > (mbuf_size * segments_nb);
> > params.dst_buf_offset = *dst_buf_offset;
> > /* Destination buffer will be one segment only */
> > - obj_size += max_size;
> > + obj_size += max_size + sizeof(struct rte_mbuf);
> > }
> >
> > *pool = rte_mempool_create_empty(pool_name,
> > --
> > 2.17.1
>
> Acked-by: Fan Zhang
Acked-by: Pablo de Lara
Re: [dpdk-dev] [PATCH v2] devtools: check %l format specifier
On 5/19/2021 8:24 PM, Thomas Monjalon wrote:
> From: Ferruh Yigit
>
> %lx or %llx tend to be wrong for 32-bit platform
> if used for fixed size variable like uint64_t.
> A checkpatch warning will avoid this common mistake.
>
> Signed-off-by: Ferruh Yigit
> Signed-off-by: Thomas Monjalon
> ---
> v2: proposal to reword the message and comment
> ---
> devtools/checkpatches.sh | 8
> 1 file changed, 8 insertions(+)
>
> diff --git a/devtools/checkpatches.sh b/devtools/checkpatches.sh
> index db4c7d8301..0e09b2cab8 100755
> --- a/devtools/checkpatches.sh
> +++ b/devtools/checkpatches.sh
> @@ -69,6 +69,14 @@ check_forbidden_additions() { #
> -f $(dirname $(readlink -f $0))/check-forbidden-tokens.awk \
> "$1" || res=1
>
> + # check %l or %ll format specifier
> + awk -v FOLDERS='lib drivers app examples' \
> + -v EXPRESSIONS='%ll*[xud]' \
> + -v RET_ON_FAIL=1 \
> + -v MESSAGE='Using %l format, should it be %PRI*64?' \
> + -f $(dirname $(readlink -f $0))/check-forbidden-tokens.awk \
> + "$1" || res=1
> +
> # forbid variable declaration inside "for" loop
> awk -v FOLDERS='.' \
> -v
> EXPRESSIONS='for[[:space:]]*\\((char|u?int|unsigned|s?size_t)' \
>
Using the %l or %ll format specifier is correct when the variable type is "long
int" or "long long int", it is only wrong if the variable type is fixed size
like 'unit64_t'.
My concern is above warning log may cause people change the correct usage.
That was why I tried to make wording less strict, more like a reminder to double
check the usage.
If we can check that format specifier is used for 'unit64_t' variable, that will
be the best solution but that is very hard to do.
Should we add a little more information to the message to prevent false hit on
the correct usage?
Re: [dpdk-dev] [PATCH v2] devtools: check %l format specifier
21/05/2021 14:01, Ferruh Yigit: > On 5/19/2021 8:24 PM, Thomas Monjalon wrote: > > From: Ferruh Yigit > > > > %lx or %llx tend to be wrong for 32-bit platform > > if used for fixed size variable like uint64_t. > > A checkpatch warning will avoid this common mistake. > > > > Signed-off-by: Ferruh Yigit > > Signed-off-by: Thomas Monjalon > > --- > > v2: proposal to reword the message and comment > > --- > > + # check %l or %ll format specifier > > + awk -v FOLDERS='lib drivers app examples' \ > > + -v EXPRESSIONS='%ll*[xud]' \ > > + -v RET_ON_FAIL=1 \ > > + -v MESSAGE='Using %l format, should it be %PRI*64?' \ > > + -f $(dirname $(readlink -f $0))/check-forbidden-tokens.awk \ > > + "$1" || res=1 > > Using the %l or %ll format specifier is correct when the variable type is > "long > int" or "long long int", it is only wrong if the variable type is fixed size > like 'unit64_t'. > > My concern is above warning log may cause people change the correct usage. > > That was why I tried to make wording less strict, more like a reminder to > double > check the usage. This is a question now: "should it be", why do you think it is strict? > If we can check that format specifier is used for 'unit64_t' variable, that > will > be the best solution but that is very hard to do. > Should we add a little more information to the message to prevent false hit on > the correct usage? Your message was: "Please check %llx usage which tends to be wrong most of the times" Mine: "Using %l format, should it be %PRI*64?" Trying to give more info about what can be wrong while keeping short: "Using %l format, is it a long variable or should it be %PRI*64?
[dpdk-dev] [PATCH v3] devtools: check %l format specifier
From: Ferruh Yigit
%lx or %llx tend to be wrong for 32-bit platform
if used for fixed size variable like uint64_t.
A checkpatch warning will avoid this common mistake.
Signed-off-by: Ferruh Yigit
Signed-off-by: Thomas Monjalon
---
v3: more explicit message
v2: proposal to reword the message and comment
---
devtools/checkpatches.sh | 8
1 file changed, 8 insertions(+)
diff --git a/devtools/checkpatches.sh b/devtools/checkpatches.sh
index ba43f84e64..c30dadd962 100755
--- a/devtools/checkpatches.sh
+++ b/devtools/checkpatches.sh
@@ -69,6 +69,14 @@ check_forbidden_additions() { #
-f $(dirname $(readlink -f $0))/check-forbidden-tokens.awk \
"$1" || res=1
+ # check %l or %ll format specifier
+ awk -v FOLDERS='lib drivers app examples' \
+ -v EXPRESSIONS='%ll*[xud]' \
+ -v RET_ON_FAIL=1 \
+ -v MESSAGE='Using %l format, prefer %PRI*64 if type is
[u]int64_t' \
+ -f $(dirname $(readlink -f $0))/check-forbidden-tokens.awk \
+ "$1" || res=1
+
# forbid variable declaration inside "for" loop
awk -v FOLDERS='.' \
-v
EXPRESSIONS='for[[:space:]]*\\((char|u?int|unsigned|s?size_t)' \
--
2.31.1
Re: [dpdk-dev] [PATCH v3] devtools: check %l format specifier
On 5/21/2021 2:30 PM, Thomas Monjalon wrote: > From: Ferruh Yigit > > %lx or %llx tend to be wrong for 32-bit platform > if used for fixed size variable like uint64_t. > A checkpatch warning will avoid this common mistake. > > Signed-off-by: Ferruh Yigit > Signed-off-by: Thomas Monjalon Ack. Thanks for update.
Re: [dpdk-dev] [PATCH v3] devtools: check %l format specifier
21/05/2021 15:33, Ferruh Yigit: > On 5/21/2021 2:30 PM, Thomas Monjalon wrote: > > From: Ferruh Yigit > > > > %lx or %llx tend to be wrong for 32-bit platform > > if used for fixed size variable like uint64_t. > > A checkpatch warning will avoid this common mistake. > > > > Signed-off-by: Ferruh Yigit > > Signed-off-by: Thomas Monjalon > > Ack. > > Thanks for update. Applied, thanks
Re: [dpdk-dev] [PATCH v3 0/4] DLB2 fixes for 21.05
21/05/2021 12:26, Ferruh Yigit: > On 5/21/2021 10:11 AM, David Marchand wrote: > > Just sending a series with 4 ordered fixes (versioned v3 since some were > > marked as v2). > > Fixed rebase damage, fixes lines and updated titles. > > Thanks David! Thanks David for cleaning last minute DLB patches. Applied DLB and DLB2 were introduced 2 releases ago but it is already a long story. We should be more cautious when integrating DLB patches in future, but it will take time and could delay integration.
Re: [dpdk-dev] [PATCH v2] doc: explain steps for improved code spell checking
21/05/2021 11:17, David Marchand: > On Fri, May 21, 2021 at 10:58 AM Thomas Monjalon wrote: > > > > The script build-dict.sh was added in DPDK 20.08. > > It generates a better dictionary for spell checking > > done via checkpatch. > > > > Signed-off-by: Thomas Monjalon > > Reviewed-by: David Marchand Applied
Re: [dpdk-dev] [PATCH v2] doc: improve lstopo tip
21/05/2021 11:06, Thomas Monjalon: > The tool lstopo from hwloc package can provide a graphical > or textual view. > In its textual form, the option --merge gives a shorter summary > which fits well with the DPDK need. > > Signed-off-by: Thomas Monjalon I think this option can be quite useful. Applied
Re: [dpdk-dev] [PATCH v2] doc: update stable section
10/03/2021 11:32, Christian Ehrhardt: > On Mon, Feb 22, 2021 at 1:38 PM Kevin Traynor wrote: > > On 19/02/2021 11:17, Kevin Traynor wrote: > > > Updating the docs to elaborate on the stable release > > > characteristics and better document the current practice > > > about new features in stable releases. > > > > > > Signed-off-by: Kevin Traynor > > > > Acked-by: Luca Boccassi > > Acked-by: Christian Ehrhardt Applied with title "doc: update backport guidelines", thanks.
[dpdk-dev] [PATCH] acl: fix build with GCC 6.3
--buildtype=debug with gcc 6.3 produces the following error:
../lib/librte_acl/acl_run_avx512_common.h: In function
‘resolve_match_idx_avx512x16’:
../lib/librte_acl/acl_run_avx512x16.h:33:18: error:
the last argument must be an 8-bit immediate
^
../lib/librte_acl/acl_run_avx512_common.h:373:9: note:
in expansion of macro ‘_M_I_’
return _M_I_(slli_epi32)(mi, match_log);
^
Seems like gcc-6.3 complains about the following construct:
static const uint32_t match_log = 5;
...
_mm512_slli_epi32(mi, match_log);
It can't substitute constant variable 'match_log' with its actual value.
The fix replaces constant variable with its immediate value.
Bugzilla ID: 717
Fixes: b64c2295f7fc ("acl: add 256-bit AVX512 classify method")
Fixes: 45da22e42ec3 ("acl: add 512-bit AVX512 classify method")
Cc: sta...@dpdk.org
Reported-by: Liang Ma
Signed-off-by: Konstantin Ananyev
---
lib/acl/acl_run_avx512.c| 8
lib/acl/acl_run_avx512_common.h | 4 ++--
lib/acl/acl_run_avx512x16.h | 6 ++
3 files changed, 8 insertions(+), 10 deletions(-)
diff --git a/lib/acl/acl_run_avx512.c b/lib/acl/acl_run_avx512.c
index 3fd1e33c3..78fbe34f7 100644
--- a/lib/acl/acl_run_avx512.c
+++ b/lib/acl/acl_run_avx512.c
@@ -4,8 +4,8 @@
#include "acl_run_sse.h"
-/*sizeof(uint32_t) << match_log == sizeof(struct rte_acl_match_results)*/
-static const uint32_t match_log = 5;
+/*sizeof(uint32_t) << ACL_MATCH_LOG == sizeof(struct rte_acl_match_results)*/
+#define ACL_MATCH_LOG 5
struct acl_flow_avx512 {
uint32_t num_packets; /* number of packets processed */
@@ -82,7 +82,7 @@ resolve_mcle8_avx512x1(uint32_t result[],
for (k = 0; k != nb_pkt; k++, result += nb_cat) {
- mi = match[k] << match_log;
+ mi = match[k] << ACL_MATCH_LOG;
for (j = 0; j != nb_cat; j += RTE_ACL_RESULTS_MULTIPLIER) {
@@ -92,7 +92,7 @@ resolve_mcle8_avx512x1(uint32_t result[],
for (i = 1, pm = match + nb_pkt; i != nb_trie;
i++, pm += nb_pkt) {
- mn = j + (pm[k] << match_log);
+ mn = j + (pm[k] << ACL_MATCH_LOG);
nr = _mm_loadu_si128((const xmm_t *)(res + mn));
np = _mm_loadu_si128((const xmm_t *)(pri + mn));
diff --git a/lib/acl/acl_run_avx512_common.h b/lib/acl/acl_run_avx512_common.h
index fbad74d45..578eaa1d0 100644
--- a/lib/acl/acl_run_avx512_common.h
+++ b/lib/acl/acl_run_avx512_common.h
@@ -393,8 +393,8 @@ static inline _T_simd
_F_(resolve_match_idx)(_T_simd mi)
{
RTE_BUILD_BUG_ON(sizeof(struct rte_acl_match_results) !=
- 1 << (match_log + 2));
- return _M_I_(slli_epi32)(mi, match_log);
+ 1 << (ACL_MATCH_LOG + 2));
+ return _M_I_(slli_epi32)(mi, ACL_MATCH_LOG);
}
/*
diff --git a/lib/acl/acl_run_avx512x16.h b/lib/acl/acl_run_avx512x16.h
index da244bc25..48bb6fed8 100644
--- a/lib/acl/acl_run_avx512x16.h
+++ b/lib/acl/acl_run_avx512x16.h
@@ -252,8 +252,6 @@ resolve_mcgt8_avx512x1(uint32_t result[],
__mmask16 cm, sm;
__m512i cp, cr, np, nr;
- const uint32_t match_log = 5;
-
res = pr->results;
pri = pr->priority;
@@ -261,7 +259,7 @@ resolve_mcgt8_avx512x1(uint32_t result[],
for (k = 0; k != nb_pkt; k++, result += nb_cat) {
- mi = match[k] << match_log;
+ mi = match[k] << ACL_MATCH_LOG;
cr = _mm512_maskz_loadu_epi32(cm, res + mi);
cp = _mm512_maskz_loadu_epi32(cm, pri + mi);
@@ -269,7 +267,7 @@ resolve_mcgt8_avx512x1(uint32_t result[],
for (i = 1, pm = match + nb_pkt; i != nb_trie;
i++, pm += nb_pkt) {
- mi = pm[k] << match_log;
+ mi = pm[k] << ACL_MATCH_LOG;
nr = _mm512_maskz_loadu_epi32(cm, res + mi);
np = _mm512_maskz_loadu_epi32(cm, pri + mi);
--
2.25.1
Re: [dpdk-dev] [PATCH v2] doc: update release notes for 21.05
21/05/2021 01:24, John McNamara: > Fix grammar, spelling and formatting of DPDK 21.05 release notes. > > Signed-off-by: John McNamara Applied, with minor improvements, biggest one being the move of eventdev crypto adapter in the middle of other eventdev news. Thanks
Re: [dpdk-dev] [PATCH] acl: fix build with GCC 6.3
On Fri, May 21, 2021 at 03:42:07PM +0100, Konstantin Ananyev wrote: I apply this patch but it caused i40e pmd avx512 build failure. not sure about the root cause. I build debug version with latest repo.
Re: [dpdk-dev] [PATCH] devtools: test different build types
On Mon, Apr 12, 2021 at 11:54 PM Thomas Monjalon wrote: > @@ -213,9 +218,10 @@ for c in gcc clang ; do > abicheck=ABI init of buildtype var is missing here. Rest lgtm. > else > abicheck=skipABI # save time and disk space > + buildtype='--buildtype=minsize' > fi > export CC="$CCACHE $c" > - build build-$c-$s $c $abicheck --default-library=$s > + build build-$c-$s $c $abicheck $buildtype --default-library=$s > unset CC > done > done -- David Marchand
Re: [dpdk-dev] [PATCH] acl: fix build with GCC 6.3
21/05/2021 16:42, Konstantin Ananyev:
> --buildtype=debug with gcc 6.3 produces the following error:
>
> ../lib/librte_acl/acl_run_avx512_common.h: In function
> ‘resolve_match_idx_avx512x16’:
> ../lib/librte_acl/acl_run_avx512x16.h:33:18: error:
> the last argument must be an 8-bit immediate
>^
> ../lib/librte_acl/acl_run_avx512_common.h:373:9: note:
> in expansion of macro ‘_M_I_’
> return _M_I_(slli_epi32)(mi, match_log);
> ^
>
> Seems like gcc-6.3 complains about the following construct:
>
> static const uint32_t match_log = 5;
> ...
> _mm512_slli_epi32(mi, match_log);
>
> It can't substitute constant variable 'match_log' with its actual value.
> The fix replaces constant variable with its immediate value.
>
> Bugzilla ID: 717
> Fixes: b64c2295f7fc ("acl: add 256-bit AVX512 classify method")
> Fixes: 45da22e42ec3 ("acl: add 512-bit AVX512 classify method")
> Cc: sta...@dpdk.org
>
> Reported-by: Liang Ma
> Signed-off-by: Konstantin Ananyev
How much critical is it?
It looks safer to wait for 21.08 cycle?
Re: [dpdk-dev] [PATCH] acl: fix build with GCC 6.3
> -Original Message-
> From: Thomas Monjalon
> Sent: Friday, May 21, 2021 4:11 PM
> To: lian...@liangbit.com; Ananyev, Konstantin
> Cc: dev@dpdk.org; sta...@dpdk.org
> Subject: Re: [dpdk-dev] [PATCH] acl: fix build with GCC 6.3
>
> 21/05/2021 16:42, Konstantin Ananyev:
> > --buildtype=debug with gcc 6.3 produces the following error:
> >
> > ../lib/librte_acl/acl_run_avx512_common.h: In function
> > ‘resolve_match_idx_avx512x16’:
> > ../lib/librte_acl/acl_run_avx512x16.h:33:18: error:
> > the last argument must be an 8-bit immediate
> >^
> > ../lib/librte_acl/acl_run_avx512_common.h:373:9: note:
> > in expansion of macro ‘_M_I_’
> > return _M_I_(slli_epi32)(mi, match_log);
> > ^
> >
> > Seems like gcc-6.3 complains about the following construct:
> >
> > static const uint32_t match_log = 5;
> > ...
> > _mm512_slli_epi32(mi, match_log);
> >
> > It can't substitute constant variable 'match_log' with its actual value.
> > The fix replaces constant variable with its immediate value.
> >
> > Bugzilla ID: 717
> > Fixes: b64c2295f7fc ("acl: add 256-bit AVX512 classify method")
> > Fixes: 45da22e42ec3 ("acl: add 512-bit AVX512 classify method")
> > Cc: sta...@dpdk.org
> >
> > Reported-by: Liang Ma
> > Signed-off-by: Konstantin Ananyev
>
> How much critical is it?
> It looks safer to wait for 21.08 cycle?
I think we can wait till 21.08 cycle.
Re: [dpdk-dev] [PATCH] acl: fix build with GCC 6.3
On Fri, May 21, 2021 at 05:10:41PM +0200, Thomas Monjalon wrote:
> 21/05/2021 16:42, Konstantin Ananyev:
> > --buildtype=debug with gcc 6.3 produces the following error:
> >
> > ../lib/librte_acl/acl_run_avx512_common.h: In function
> > ‘resolve_match_idx_avx512x16’:
> > ../lib/librte_acl/acl_run_avx512x16.h:33:18: error:
> > the last argument must be an 8-bit immediate
> >^
> > ../lib/librte_acl/acl_run_avx512_common.h:373:9: note:
> > in expansion of macro ‘_M_I_’
> > return _M_I_(slli_epi32)(mi, match_log);
> > ^
> >
> > Seems like gcc-6.3 complains about the following construct:
> >
> > static const uint32_t match_log = 5;
> > ...
> > _mm512_slli_epi32(mi, match_log);
> >
> > It can't substitute constant variable 'match_log' with its actual value.
> > The fix replaces constant variable with its immediate value.
> >
> > Bugzilla ID: 717
> > Fixes: b64c2295f7fc ("acl: add 256-bit AVX512 classify method")
> > Fixes: 45da22e42ec3 ("acl: add 512-bit AVX512 classify method")
> > Cc: sta...@dpdk.org
> >
> > Reported-by: Liang Ma
> > Signed-off-by: Konstantin Ananyev
>
> How much critical is it?
> It looks safer to wait for 21.08 cycle?
+1. gcc8.30 is OK. It's a bit late now.
>
>
Re: [dpdk-dev] [dpdk-dev v1] cperf: fix crypto perf out-of-place mempool alloc
> > > Add in missing rte_mbuf size in mempool allocation for out-of-place op.
> > >
> > > Fixes: bf9d6702eca9 ("app/crypto-perf: use single mempool")
> > > Cc: pablo.de.lara.gua...@intel.com
> > >
> > > Signed-off-by: Kai Ji
> > Acked-by: Fan Zhang
> Acked-by: Pablo de Lara
Given the root cause is 3 years old, it is probably not urgent enough
to be merged in the last day of 21.05.
I won't take any risk at this stage.
[dpdk-dev] [PATCH] version: 21.08-rc0
Start a new release cycle with empty release notes.
Signed-off-by: David Marchand
---
.github/workflows/build.yml| 2 +-
.travis.yml| 2 +-
ABI_VERSION| 2 +-
VERSION| 2 +-
doc/guides/rel_notes/index.rst | 1 +
doc/guides/rel_notes/release_21_08.rst | 138 +
6 files changed, 143 insertions(+), 4 deletions(-)
create mode 100644 doc/guides/rel_notes/release_21_08.rst
diff --git a/.github/workflows/build.yml b/.github/workflows/build.yml
index d38feace69..7c4d6dcdbf 100644
--- a/.github/workflows/build.yml
+++ b/.github/workflows/build.yml
@@ -21,7 +21,7 @@ jobs:
CC: ccache ${{ matrix.config.compiler }}
DEF_LIB: ${{ matrix.config.library }}
LIBABIGAIL_VERSION: libabigail-1.8
- REF_GIT_TAG: v21.02
+ REF_GIT_TAG: v21.05
RUN_TESTS: ${{ contains(matrix.config.checks, 'tests') }}
strategy:
diff --git a/.travis.yml b/.travis.yml
index 898cffd998..5b702cc9bb 100644
--- a/.travis.yml
+++ b/.travis.yml
@@ -41,7 +41,7 @@ script: ./.ci/${TRAVIS_OS_NAME}-build.sh
env:
global:
- LIBABIGAIL_VERSION=libabigail-1.8
-- REF_GIT_TAG=v21.02
+- REF_GIT_TAG=v21.05
jobs:
include:
diff --git a/ABI_VERSION b/ABI_VERSION
index c598172d8d..8e5954eb6f 100644
--- a/ABI_VERSION
+++ b/ABI_VERSION
@@ -1 +1 @@
-21.2
+21.3
diff --git a/VERSION b/VERSION
index 2b2dbfd3c8..1b43c9e062 100644
--- a/VERSION
+++ b/VERSION
@@ -1 +1 @@
-21.05.0
+21.08.0-rc0
diff --git a/doc/guides/rel_notes/index.rst b/doc/guides/rel_notes/index.rst
index 4c423c8d9a..9648ba60e1 100644
--- a/doc/guides/rel_notes/index.rst
+++ b/doc/guides/rel_notes/index.rst
@@ -8,6 +8,7 @@ Release Notes
:maxdepth: 1
:numbered:
+release_21_08
release_21_05
release_21_02
release_20_11
diff --git a/doc/guides/rel_notes/release_21_08.rst
b/doc/guides/rel_notes/release_21_08.rst
new file mode 100644
index 00..a6ecfdf3ce
--- /dev/null
+++ b/doc/guides/rel_notes/release_21_08.rst
@@ -0,0 +1,138 @@
+.. SPDX-License-Identifier: BSD-3-Clause
+ Copyright 2021 The DPDK contributors
+
+.. include::
+
+DPDK Release 21.08
+==
+
+.. **Read this first.**
+
+ The text in the sections below explains how to update the release notes.
+
+ Use proper spelling, capitalization and punctuation in all sections.
+
+ Variable and config names should be quoted as fixed width text:
+ ``LIKE_THIS``.
+
+ Build the docs and view the output file to ensure the changes are correct::
+
+ make doc-guides-html
+ xdg-open build/doc/html/guides/rel_notes/release_21_08.html
+
+
+New Features
+
+
+.. This section should contain new features added in this release.
+ Sample format:
+
+ * **Add a title in the past tense with a full stop.**
+
+ Add a short 1-2 sentence description in the past tense.
+ The description should be enough to allow someone scanning
+ the release notes to understand the new feature.
+
+ If the feature adds a lot of sub-features you can use a bullet list
+ like this:
+
+ * Added feature foo to do something.
+ * Enhanced feature bar to do something else.
+
+ Refer to the previous release notes for examples.
+
+ Suggested order in release notes items:
+ * Core libs (EAL, mempool, ring, mbuf, buses)
+ * Device abstraction libs and PMDs (ordered alphabetically by vendor name)
+ - ethdev (lib, PMDs)
+ - cryptodev (lib, PMDs)
+ - eventdev (lib, PMDs)
+ - etc
+ * Other libs
+ * Apps, Examples, Tools (if significant)
+
+ This section is a comment. Do not overwrite or remove it.
+ Also, make sure to start the actual text at the margin.
+ ===
+
+
+Removed Items
+-
+
+.. This section should contain removed items in this release. Sample format:
+
+ * Add a short 1-2 sentence description of the removed item
+ in the past tense.
+
+ This section is a comment. Do not overwrite or remove it.
+ Also, make sure to start the actual text at the margin.
+ ===
+
+
+API Changes
+---
+
+.. This section should contain API changes. Sample format:
+
+ * sample: Add a short 1-2 sentence description of the API change
+ which was announced in the previous releases and made in this release.
+ Start with a scope label like "ethdev:".
+ Use fixed width quotes for ``function_names`` or ``struct_names``.
+ Use the past tense.
+
+ This section is a comment. Do not overwrite or remove it.
+ Also, make sure to start the actual text at the margin.
+ ===
+
+
+ABI Changes
+---
+
+.. This section should contain ABI changes. Sample format:
+
+ * sample: Add a short 1-2 sentence description of the ABI change
+ which was announced in th
[dpdk-dev] [dpdk-announce] DPDK 21.05 released
A new release is available: https://fast.dpdk.org/rel/dpdk-21.05.tar.xz It was a quite big cycle as usual with May releases: 1352 commits from 176 authors 2396 files changed, 134413 insertions(+), 63913 deletions(-) It is not planned to start a maintenance branch for 21.05. This version is ABI-compatible with 20.11 and 21.02. Below are some new features: * General - compilation support for GCC 11, clang 12 and Alpine Linux - mass renaming of lib directories - allow disabling some libraries - log names alignment and help command - phase-fair lock - Marvell CN10K driver * Networking - predictable RSS - port representor syntax for sub-function and multi-host - metering extended to flow rule matching - packet integrity in flow rule matching - TCP connection tracking offload with flow rule - Windows support of ice, pcap and vmxnet3 drivers More details in the release notes: https://doc.dpdk.org/guides/rel_notes/release_21_05.html There are 41 new contributors (including authors, reviewers and testers). Welcome to Alexandre Ferrieux, Amir Shay, Ashish Paul, Ashwin Sekhar T K, Chaoyong He, David Bouyeure, Dheemanth Mallikarjun, Elad Nachman, Gabriel Ganne, Haifei Luo, Hengjian Zhang, Jie Wang, John Hurley, Joshua Hay, Junjie Wan, Kai Ji, Kamil Vojanec, Kathleen Capella, Keiichi Watanabe, Luc Pelletier, Maciej Machnikowski, Piotr Kubaj, Pu Xu, Richael Zhuang, Robert Malz, Roy Shterman, Salem Sol, Shay Agroskin, Shun Hao, Siwar Zitouni, Smadar Fuks, Sridhar Samudrala, Srikanth Yalavarthi, Stanislaw Kardach, Stefan Wegrzyn, Tengfei Zhang, Tianyu Li, Vidya Sagar Velumuri, Vishwas Danivas, Wenwu Ma and Yan Xia. Below is the number of commits per employer (with authors count): 352 Intel (54) 262 Nvidia (24) 220 Huawei (9) 148 Marvell (18) 61 Broadcom (5) 60 Red Hat (5) 34 NXP (7) 31 Trustnet (1) 26 OKTET Labs (4) 21 Semihalf (2) 19 Microsoft (4) 16 Pensando (1) 14 BIFIT (1) 10 Xilinx (3) 9 Arm (6) 8 Emumba (1) 7 PANTHEON.tech (1) 7 Atomic Rules (1) 7 6WIND (4) 6 Alpine Linux (1) 4 Cisco (2) 3 IBM (2) 3 Amazon (2) Based on Reviewed-by and Acked-by tags, the top non-PMD reviewers are: 46 Ferruh Yigit 39 David Marchand 34 Andrew Rybchenko 30 Bruce Richardson 27 Maxime Coquelin 26 Viacheslav Ovsiienko 25 Akhil Goyal 23 Thomas Monjalon 22 Jerin Jacob 20 Ajit Khaparde 18 Xiaoyun Li 18 Anatoly Burakov 16 Ori Kam 12 Matan Azrad 12 Konstantin Ananyev 12 Honnappa Nagarahalli 11 Olivier Matz 11 Hemant Agrawal 10 Ruifeng Wang The new features for 21.08 may be submitted during the next 12 days. DPDK 21.08 should be released on early August, in a tight schedule: http://core.dpdk.org/roadmap#dates Please share your features roadmap. Thanks everyone for allowing to close a great 21.05 on 21/05
Re: [dpdk-dev] [PATCH] version: 21.08-rc0
21/05/2021 18:45, David Marchand: > Start a new release cycle with empty release notes. > > Signed-off-by: David Marchand Acked-by: Thomas Monjalon Let's start a new cycle, yeah!
