[PATCH v2] doc: update doc for idpf and cpfl
From: Beilei Xing Add recommended matching list for idpf pmd and cpfl pmd. Signed-off-by: Beilei Xing --- v2 change: - Remove description about 23.03 doc/guides/nics/cpfl.rst | 14 ++ doc/guides/nics/idpf.rst | 14 ++ 2 files changed, 28 insertions(+) diff --git a/doc/guides/nics/cpfl.rst b/doc/guides/nics/cpfl.rst index e88008e16e..06a18694b4 100644 --- a/doc/guides/nics/cpfl.rst +++ b/doc/guides/nics/cpfl.rst @@ -21,6 +21,20 @@ To get better performance on Intel platforms, please follow the :doc:`../linux_gsg/nic_perf_intel_platform`. +Recommended Matching List +- + +It is highly recommended to upgrade the MEV-ts release to avoid the compatibility issues +with the cpfl PMD. +Here is the suggested matching list which has been tested and verified. + + ++--+ + | DPDK | MEV-ts release | + ++==+ + |23.07 | 0.9.1 | + ++--+ + + Configuration - diff --git a/doc/guides/nics/idpf.rst b/doc/guides/nics/idpf.rst index 3693d82255..89351f1a22 100644 --- a/doc/guides/nics/idpf.rst +++ b/doc/guides/nics/idpf.rst @@ -19,6 +19,20 @@ To get better performance on Intel platforms, please follow the :doc:`../linux_gsg/nic_perf_intel_platform`. +Recommended Matching List +- + +It is highly recommended to upgrade the idpf kernel driver, MEV-ts release to avoid +the compatibility issues with the idpf PMD. +Here is the suggested matching list which has been tested and verified. + + ++---+--+ + |DPDK| Kernel Driver | MEV-ts release | + ++===+==+ + |23.07 |0.0.710| 0.9.1 | + ++---+--+ + + Configuration - -- 2.34.1
Re: [dpdk-dev] [PATCH v1] doc: add inbuilt graph nodes data flow
> > From: Jerin Jacob > > > > Added diagram to depict the data flow between inbuilt graph nodes. > > > > In order to avoid graphviz package dependency to DPDK documentation, manual > > step added to create a svg file from the dot file. The details for the same > > is > > documented in graph_inbuilt_node_flow.svg as a comment. > > > > Signed-off-by: Jerin Jacob > > Reviewed-by: Zhirun Yan Applied, thanks.
Re: [PATCH] doc: announce deprecation of RTE_CPUFLAG_NUMFLAGS
On 7/12/2023 11:18 AM, Sivaprasad Tummala wrote: > To allow new cpu features to be added without ABI breakage, > RTE_CPUFLAG_NUMFLAGS will be removed in DPDK 23.11 release. > > Signed-off-by: Sivaprasad Tummala > --- > doc/guides/rel_notes/deprecation.rst | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/doc/guides/rel_notes/deprecation.rst > b/doc/guides/rel_notes/deprecation.rst > index 8e1cdd677a..92db59d9c2 100644 > --- a/doc/guides/rel_notes/deprecation.rst > +++ b/doc/guides/rel_notes/deprecation.rst > @@ -28,6 +28,9 @@ Deprecation Notices >the replacement API rte_thread_set_name and rte_thread_create_control being >marked as stable, and planned to be removed by the 23.11 release. > > +* eal: RTE_CPUFLAG_NUMFLAGS will be removed in DPDK 23.11 release. This is > + to allow new cpu features to be added without ABI breakage. > + > * rte_atomicNN_xxx: These APIs do not take memory order parameter. This does >not allow for writing optimized code for all the CPU architectures > supported >in DPDK. DPDK has adopted the atomic operations from +techboard, Request for review/ack, patch is to remove ABI restriction to add new CPU flags.
Re: [PATCH v1] doc: deprecation notice to add callback data to rte_event_fp_ops
On 7/17/2023 12:24 PM, Sivaprasad Tummala wrote: > Deprecation notice to add "rte_eventdev_port_data" field to > ``rte_event_fp_ops`` for callback support. > > Signed-off-by: Sivaprasad Tummala > --- > doc/guides/rel_notes/deprecation.rst | 7 +++ > 1 file changed, 7 insertions(+) > > diff --git a/doc/guides/rel_notes/deprecation.rst > b/doc/guides/rel_notes/deprecation.rst > index fb771a0305..057f97ce5a 100644 > --- a/doc/guides/rel_notes/deprecation.rst > +++ b/doc/guides/rel_notes/deprecation.rst > @@ -130,6 +130,13 @@ Deprecation Notices >``rte_cryptodev_get_auth_algo_string``, > ``rte_cryptodev_get_aead_algo_string`` and >``rte_cryptodev_asym_get_xform_string`` respectively. > > +* eventdev: The struct rte_event_fp_ops will be updated with a new element > + rte_eventdev_port_data to support optional callbacks in DPDK 23.11. > + rte_eventdev_port_data is used to hold callbacks registered optionally > + per event device port and associated callback data. By adding > rte_eventdev_port_data > + to rte_event_fp_ops, allows to fetch this data for fastpath eventdev > inline functions > + in advance. This changes the size of rte_event_fp_ops and result in ABI > change. > + > * security: Hide structures ``rte_security_ops`` and ``rte_security_ctx`` >as these are internal to DPDK library and drivers. > +techboard, Request for review/ack, patch is to extend eventdev to support callbacks per packet.
Re: [PATCH] doc: announce deprecation of RTE_CPUFLAG_NUMFLAGS
On Tue, Jul 25, 2023 at 09:39:15AM +0100, Ferruh Yigit wrote: > On 7/12/2023 11:18 AM, Sivaprasad Tummala wrote: > > To allow new cpu features to be added without ABI breakage, > > RTE_CPUFLAG_NUMFLAGS will be removed in DPDK 23.11 release. > > > > Signed-off-by: Sivaprasad Tummala > > --- > > doc/guides/rel_notes/deprecation.rst | 3 +++ > > 1 file changed, 3 insertions(+) > > > > diff --git a/doc/guides/rel_notes/deprecation.rst > > b/doc/guides/rel_notes/deprecation.rst > > index 8e1cdd677a..92db59d9c2 100644 > > --- a/doc/guides/rel_notes/deprecation.rst > > +++ b/doc/guides/rel_notes/deprecation.rst > > @@ -28,6 +28,9 @@ Deprecation Notices > >the replacement API rte_thread_set_name and rte_thread_create_control > > being > >marked as stable, and planned to be removed by the 23.11 release. > > > > +* eal: RTE_CPUFLAG_NUMFLAGS will be removed in DPDK 23.11 release. This is > > + to allow new cpu features to be added without ABI breakage. > > + > > * rte_atomicNN_xxx: These APIs do not take memory order parameter. This > > does > >not allow for writing optimized code for all the CPU architectures > > supported > >in DPDK. DPDK has adopted the atomic operations from > > +techboard, > > Request for review/ack, patch is to remove ABI restriction to add new > CPU flags. Acked-by: Bruce Richardson
[PATCH v3] dts: update dependencies and mypy execution
Poetry changed the syntax of dev dependencies section in version
1.2.0. Updated the lock file with Poetry 1.5.1 added that to the
documentation.
The scripts section did nothing, so it got removed.
Update Pylama linters:
* pep8 is the same as pycodestyle
* pylint is missing dependencies and thus not executed. It reports a
number of warnings and may be introduced in a future patch.
* mypy doesn't work properly with Pylama. Pylama executes linting
file-by-file and mypy works on all files at once.
Mypy has thus been moved outside Pylama and is executed separately.
Added Mypy configuration that makes it easier to specify ignored issues
in more detail.
Signed-off-by: Juraj Linkeš
---
devtools/dts-check-format.sh | 21 +-
doc/guides/tools/dts.rst | 1 +
dts/framework/config/__init__.py | 2 +-
.../remote/interactive_remote_session.py | 4 +-
.../remote/interactive_shell.py | 2 +-
dts/poetry.lock | 643 ++
dts/pyproject.toml| 27 +-
7 files changed, 554 insertions(+), 146 deletions(-)
diff --git a/devtools/dts-check-format.sh b/devtools/dts-check-format.sh
index c9b3702642..3f43e17e88 100755
--- a/devtools/dts-check-format.sh
+++ b/devtools/dts-check-format.sh
@@ -1,6 +1,7 @@
#!/bin/sh
# SPDX-License-Identifier: BSD-3-Clause
# Copyright(c) 2022 University of New Hampshire
+# Copyright(c) 2023 PANTHEON.tech s.r.o.
usage() {
echo "Usage: $(basename $0) [options] [directory]"
@@ -11,9 +12,10 @@ usage() {
format=true
lint=true
+typecheck=true
# Comments after args serve as documentation; must be present
-while getopts "hfl" arg; do
+while getopts "hflt" arg; do
case $arg in
h) # Display this message
echo 'Run formatting and linting programs for DTS.'
@@ -26,6 +28,9 @@ while getopts "hfl" arg; do
l) # Don't run linter
lint=false
;;
+ t) # Don't run type checker
+ typecheck=false
+ ;;
?)
usage
exit 1
@@ -93,6 +98,20 @@ if $lint; then
fi
fi
+if $typecheck; then
+ if $format || $lint; then
+ echo
+ fi
+ heading "Checking types in $directory/"
+ if command -v mypy > /dev/null; then
+ mypy .
+ errors=$((errors + $?))
+ else
+ echo "mypy not found, unable to check types"
+ errors=$((errors + 1))
+ fi
+fi
+
echo
heading "Summary for $directory/"
echo "Found $errors errors"
diff --git a/doc/guides/tools/dts.rst b/doc/guides/tools/dts.rst
index 2f97d1df6e..32c18ee472 100644
--- a/doc/guides/tools/dts.rst
+++ b/doc/guides/tools/dts.rst
@@ -82,6 +82,7 @@ Setting up DTS environment
Another benefit is the usage of ``pyproject.toml``, which has become the
standard config file
for python projects, improving project organization.
To install Poetry, visit their `doc pages
RE: [PATCH] doc: announce deprecation of RTE_CPUFLAG_NUMFLAGS
> From: Ferruh Yigit [mailto:ferruh.yi...@amd.com] > Sent: Tuesday, 25 July 2023 10.39 > > On 7/12/2023 11:18 AM, Sivaprasad Tummala wrote: > > To allow new cpu features to be added without ABI breakage, > > RTE_CPUFLAG_NUMFLAGS will be removed in DPDK 23.11 release. > > > > Signed-off-by: Sivaprasad Tummala > > --- Acked-by: Morten Brørup
Re: [PATCH] doc: announce deprecation of RTE_CPUFLAG_NUMFLAGS
On 25/07/2023 09:39, Ferruh Yigit wrote: On 7/12/2023 11:18 AM, Sivaprasad Tummala wrote: To allow new cpu features to be added without ABI breakage, RTE_CPUFLAG_NUMFLAGS will be removed in DPDK 23.11 release. Signed-off-by: Sivaprasad Tummala --- doc/guides/rel_notes/deprecation.rst | 3 +++ 1 file changed, 3 insertions(+) diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst index 8e1cdd677a..92db59d9c2 100644 --- a/doc/guides/rel_notes/deprecation.rst +++ b/doc/guides/rel_notes/deprecation.rst @@ -28,6 +28,9 @@ Deprecation Notices the replacement API rte_thread_set_name and rte_thread_create_control being marked as stable, and planned to be removed by the 23.11 release. +* eal: RTE_CPUFLAG_NUMFLAGS will be removed in DPDK 23.11 release. This is + to allow new cpu features to be added without ABI breakage. + * rte_atomicNN_xxx: These APIs do not take memory order parameter. This does not allow for writing optimized code for all the CPU architectures supported in DPDK. DPDK has adopted the atomic operations from +techboard, Request for review/ack, patch is to remove ABI restriction to add new CPU flags. Acked-by: Kevin Traynor
Deprecation Notices history
Why are Deprecation Notices not part of the Release Notes? If a DPDK developer wants to upgrade his application from e.g. 20.11 to 22.11, it might be informative to review the historical Deprecation Notices. Is it because we promise that (when the announced change actually occurs) the deleted Deprecation Notice entry is replaced by a Release Note entry? Anyway, I think that historical Deprecation Notices should be publicly available on the web site and/or with the Release Notes, and not only available in the GIT log. Med venlig hilsen / Kind regards, -Morten Brørup
Re: [PATCH v4 2/2] doc/contributing: guidelines for logging, tracing and telemetry
20/07/2023 13:05, Bruce Richardson: > --- a/doc/guides/prog_guide/telemetry_lib.rst > +++ b/doc/guides/prog_guide/telemetry_lib.rst > @@ -1,6 +1,8 @@ > .. SPDX-License-Identifier: BSD-3-Clause > Copyright(c) 2020 Intel Corporation. > > +.. _telemetry_library: > + > Telemetry Library > = No need to add such anchor at the beginning of a file. The syntax :doc: can be used to reference such page. I fix it while applying. Applied, thanks.
Re: release candidate 23.07-rc4
IBM - Power Systems DPDK v23.07-rc4 * Build CI on Fedora 30,31,34,36,37 for ppc64le * Basic PF on Mellanox: No issue found * Performance: not tested. * OS: RHEL 9.1 kernel: 5.14.0-162.6.1.el9_1.ppc64le with gcc version 11.3.1 20220421 (Red Hat 11.3.1-2) (GCC) RHEL 8.8 kernel: 4.18.0-477.10.1.el8_8.ppc64le with gcc version 8.5.0 20210514 (Red Hat 8.5.0-18) (GCC) RHEL 8.4 kernel: 4.18.0-305.72.1.el8_4.ppc64le with gcc version 8.4.1 20200928 (Red Hat 8.4.1-1) (GCC) Systems tested: - LPARs on IBM Power10 CHRP IBM,9105-22A NICs: - Mellanox Mellanox Technologies MT2894 Family [ConnectX-6 Lx] - firmware version: 26.37.1014 - MLNX_OFED_LINUX-23.04-0.5.3.6 - LPARs on Power9 IBM,9009-42G NICs: - Mellanox Technologies MT28800 Family [ConnectX-5 Ex] - firmware-version: 16.35.2000 - MLNX_OFED_LINUX-23.04-0.5.3.6 Regards, Thinh Tran On 7/20/2023 12:15 AM, Thomas Monjalon wrote: A new DPDK release candidate is ready for testing: https://git.dpdk.org/dpdk/tag/?id=v23.07-rc4 There are 37 new patches in this snapshot. Release notes: https://doc.dpdk.org/guides/rel_notes/release_23_07.html Except few policy updates and last minute release notes, everything ready and not risky should be there in DPDK 23.07-rc4. Do not forget to review the deprecation notices. You may share some release validation results by replying to this message at dev@dpdk.org and by adding tested hardware in the release notes. Please think about sharing your roadmap now for DPDK 23.11. Thank you everyone
Re: [PATCH] doc: announce deprecation of RTE_CPUFLAG_NUMFLAGS
On Tue, Jul 25, 2023 at 09:39:15AM +0100, Ferruh Yigit wrote: > On 7/12/2023 11:18 AM, Sivaprasad Tummala wrote: > > To allow new cpu features to be added without ABI breakage, > > RTE_CPUFLAG_NUMFLAGS will be removed in DPDK 23.11 release. > > > > Signed-off-by: Sivaprasad Tummala > > --- > > doc/guides/rel_notes/deprecation.rst | 3 +++ > > 1 file changed, 3 insertions(+) > > > > diff --git a/doc/guides/rel_notes/deprecation.rst > > b/doc/guides/rel_notes/deprecation.rst > > index 8e1cdd677a..92db59d9c2 100644 > > --- a/doc/guides/rel_notes/deprecation.rst > > +++ b/doc/guides/rel_notes/deprecation.rst > > @@ -28,6 +28,9 @@ Deprecation Notices > >the replacement API rte_thread_set_name and rte_thread_create_control > > being > >marked as stable, and planned to be removed by the 23.11 release. > > > > +* eal: RTE_CPUFLAG_NUMFLAGS will be removed in DPDK 23.11 release. This is > > + to allow new cpu features to be added without ABI breakage. > > + > > * rte_atomicNN_xxx: These APIs do not take memory order parameter. This > > does > >not allow for writing optimized code for all the CPU architectures > > supported > >in DPDK. DPDK has adopted the atomic operations from > > +techboard, > > Request for review/ack, patch is to remove ABI restriction to add new > CPU flags. Acked-by: Tyler Retzlaff
Re: [PATCH] doc: announce deprecation of RTE_CPUFLAG_NUMFLAGS
On Tue, Jul 25, 2023 at 7:48 PM Tyler Retzlaff wrote: > > On Tue, Jul 25, 2023 at 09:39:15AM +0100, Ferruh Yigit wrote: > > On 7/12/2023 11:18 AM, Sivaprasad Tummala wrote: > > > To allow new cpu features to be added without ABI breakage, > > > RTE_CPUFLAG_NUMFLAGS will be removed in DPDK 23.11 release. > > > > > > Signed-off-by: Sivaprasad Tummala > > > --- > > > doc/guides/rel_notes/deprecation.rst | 3 +++ > > > 1 file changed, 3 insertions(+) > > > > > > diff --git a/doc/guides/rel_notes/deprecation.rst > > > b/doc/guides/rel_notes/deprecation.rst > > > index 8e1cdd677a..92db59d9c2 100644 > > > --- a/doc/guides/rel_notes/deprecation.rst > > > +++ b/doc/guides/rel_notes/deprecation.rst > > > @@ -28,6 +28,9 @@ Deprecation Notices > > >the replacement API rte_thread_set_name and rte_thread_create_control > > > being > > >marked as stable, and planned to be removed by the 23.11 release. > > > > > > +* eal: RTE_CPUFLAG_NUMFLAGS will be removed in DPDK 23.11 release. This > > > is > > > + to allow new cpu features to be added without ABI breakage. > > > + > > > * rte_atomicNN_xxx: These APIs do not take memory order parameter. This > > > does > > >not allow for writing optimized code for all the CPU architectures > > > supported > > >in DPDK. DPDK has adopted the atomic operations from > > > > +techboard, > > > > Request for review/ack, patch is to remove ABI restriction to add new > > CPU flags. > > Acked-by: Tyler Retzlaff Acked-by: Jerin Jacob
[Bug 1268] dma/idxd appends extra characters which makes test-dma-perf to fail.
https://bugs.dpdk.org/show_bug.cgi?id=1268 Bug ID: 1268 Summary: dma/idxd appends extra characters which makes test-dma-perf to fail. Product: DPDK Version: 23.07 Hardware: x86 OS: Linux Status: UNCONFIRMED Severity: normal Priority: Normal Component: other Assignee: dev@dpdk.org Reporter: vipin.vargh...@amd.com Target Milestone: --- Created attachment 256 --> https://bugs.dpdk.org/attachment.cgi?id=256&action=edit name change before-after setup details: 1. CPU: Intel(R) Xeon(R) Gold 6421N 2. OS: Ubuntu 22.04.2 LTS 3. gcc: gcc version 11.3.0 (Ubuntu 11.3.0-1ubuntu1~22.04.1) 4. DPDk version: `https://git.dpdk.org/dpdk/tag/?id=v23.07-rc4` 5. DSA Acceleration: `f2:01.0 System peripheral: Intel Corporation Device 0b25` 6. application: `./build/app/dpdk-test-dma-perf` 7. arguments: `-l8-31 --log-level=pmd,8 -a :f2:01.0 --config app/test-dma-perf/my.ini` 8. driver used: vfio-pci on PF INI config file: ``` [case1] type=DMA_MEM_COPY mem_size=10 buf_size=64,64,0,ADD dma_ring_size=1024 kick_batch=32 src_numa_node=0 dst_numa_node=0 cache_flush=0 test_seconds=10 lcore_dma=lcore10@:f2:01.0 #lcore_dma=lcore10@:00:04.2, lcore11@:00:04.3 eal_args=--in-memory --file-prefix=test-dma-hw ``` issue logs: ``` Running scenario 1 Error: Fail to find DMA :f2:01.0. Not enough dmadevs (0) for all workers (1). Stopping dmadev 0 dma: Device 0 already stopped. No proper operation for variable entry. ``` reason for failure: the device name is populated from `idxd_pci.c` as `:f2:01.0-q0` actions tried: 1. modified by forcing `--proc-type=primary`. same issue 2. modified name in ini `:f2:01.0-q0`, worked. Checking the driver/dma/idxd_pci.c show cases the issue comes because the application is identified as `RTE_SECONDARY`. attaching screen shot for the same. -- You are receiving this mail because: You are the assignee for the bug.
[PATCH] doc/dmadevs: add note clarifying naming of idxd devices
Since the test-dma-perf application identifies devices by name, include in the idxd driver documentation a note on device naming when vfio-pci. See also discussion in bugzilla[1]. [1] https://bugs.dpdk.org/show_bug.cgi?id=1268 Signed-off-by: Bruce Richardson --- doc/guides/dmadevs/idxd.rst | 7 +++ 1 file changed, 7 insertions(+) diff --git a/doc/guides/dmadevs/idxd.rst b/doc/guides/dmadevs/idxd.rst index ea101031bf..a9a788ac56 100644 --- a/doc/guides/dmadevs/idxd.rst +++ b/doc/guides/dmadevs/idxd.rst @@ -123,6 +123,13 @@ For example:: $ dpdk-devbind.py -b vfio-pci 6a:01.0 +.. note:: + + Since each individual queue on the HW device is its own separate dmadev instance, + the internal DMA device name includes the HW queue id as a suffix on the PCI id. + The above device when used by a DPDK application will be accessible via dmadevs with names: + ``:6a:01.0-q0``, ``6a:01.0-q1``, etc. + Device Probing and Initialization ~~ -- 2.39.2
Re: [PATCH] doc/dmadevs: add note clarifying naming of idxd devices
On Tue, Jul 25, 2023 at 05:16:29PM +0100, Bruce Richardson wrote: > Since the test-dma-perf application identifies devices by name, include > in the idxd driver documentation a note on device naming when vfio-pci. > See also discussion in bugzilla[1]. > > [1] https://bugs.dpdk.org/show_bug.cgi?id=1268 > > Signed-off-by: Bruce Richardson > --- Note, although I reference bugzilla here, I don't consider this a bugfix, so I've not included a fixes tag and official bugzilla id etc. It's instead a note clarifying the expected behaviour. /Bruce
RE: [PATCH] doc: announce deprecation of RTE_CPUFLAG_NUMFLAGS
> -Original Message- > > On Tue, Jul 25, 2023 at 7:48 PM Tyler Retzlaff > wrote: > > > > On Tue, Jul 25, 2023 at 09:39:15AM +0100, Ferruh Yigit wrote: > > > On 7/12/2023 11:18 AM, Sivaprasad Tummala wrote: > > > > To allow new cpu features to be added without ABI breakage, > > > > RTE_CPUFLAG_NUMFLAGS will be removed in DPDK 23.11 release. > > > > > > > > Signed-off-by: Sivaprasad Tummala > > > > --- > > > > doc/guides/rel_notes/deprecation.rst | 3 +++ > > > > 1 file changed, 3 insertions(+) > > > > > > > > diff --git a/doc/guides/rel_notes/deprecation.rst > > > > b/doc/guides/rel_notes/deprecation.rst > > > > index 8e1cdd677a..92db59d9c2 100644 > > > > --- a/doc/guides/rel_notes/deprecation.rst > > > > +++ b/doc/guides/rel_notes/deprecation.rst > > > > @@ -28,6 +28,9 @@ Deprecation Notices > > > >the replacement API rte_thread_set_name and > rte_thread_create_control being > > > >marked as stable, and planned to be removed by the 23.11 release. > > > > > > > > +* eal: RTE_CPUFLAG_NUMFLAGS will be removed in DPDK 23.11 > > > > +release. This is > > > > + to allow new cpu features to be added without ABI breakage. > > > > + > > > > * rte_atomicNN_xxx: These APIs do not take memory order parameter. > This does > > > >not allow for writing optimized code for all the CPU architectures > supported > > > >in DPDK. DPDK has adopted the atomic operations from > > > > > > +techboard, > > > > > > Request for review/ack, patch is to remove ABI restriction to add > > > new CPU flags. > > > > Acked-by: Tyler Retzlaff > > Acked-by: Jerin Jacob Acked-by: Hemant Agrawal
RE: [PATCH v1] doc: deprecation notice to add callback data to rte_event_fp_ops
> -Original Message- > From: Ferruh Yigit > Sent: Tuesday, July 25, 2023 2:11 PM > To: Sivaprasad Tummala ; dev@dpdk.org > Cc: bruce.richard...@intel.com; david.march...@redhat.com; > tho...@monjalon.net; jerinjac...@gmail.com; techbo...@dpdk.org > Subject: Re: [PATCH v1] doc: deprecation notice to add callback data to > rte_event_fp_ops > > On 7/17/2023 12:24 PM, Sivaprasad Tummala wrote: > > Deprecation notice to add "rte_eventdev_port_data" field to > > ``rte_event_fp_ops`` for callback support. > > > > Signed-off-by: Sivaprasad Tummala > > --- > > doc/guides/rel_notes/deprecation.rst | 7 +++ > > 1 file changed, 7 insertions(+) > > > > diff --git a/doc/guides/rel_notes/deprecation.rst > > b/doc/guides/rel_notes/deprecation.rst > > index fb771a0305..057f97ce5a 100644 > > --- a/doc/guides/rel_notes/deprecation.rst > > +++ b/doc/guides/rel_notes/deprecation.rst > > @@ -130,6 +130,13 @@ Deprecation Notices > >``rte_cryptodev_get_auth_algo_string``, > ``rte_cryptodev_get_aead_algo_string`` and > >``rte_cryptodev_asym_get_xform_string`` respectively. > > > > +* eventdev: The struct rte_event_fp_ops will be updated with a new > > +element > > + rte_eventdev_port_data to support optional callbacks in DPDK 23.11. > > + rte_eventdev_port_data is used to hold callbacks registered > > +optionally > > + per event device port and associated callback data. By adding > > +rte_eventdev_port_data > > + to rte_event_fp_ops, allows to fetch this data for fastpath > > +eventdev inline functions > > + in advance. This changes the size of rte_event_fp_ops and result in ABI > change. > > + > > * security: Hide structures ``rte_security_ops`` and ``rte_security_ctx`` > >as these are internal to DPDK library and drivers. > > > > +techboard, > > Request for review/ack, patch is to extend eventdev to support callbacks per > packet. Acked-by: Hemant Agrawal
RE: [PATCH v1] doc: deprecation notice to add callback data to rte_event_fp_ops
> > -Original Message- > > From: Ferruh Yigit > > Sent: Tuesday, July 25, 2023 2:11 PM > > To: Sivaprasad Tummala ; dev@dpdk.org > > Cc: bruce.richard...@intel.com; david.march...@redhat.com; > > tho...@monjalon.net; jerinjac...@gmail.com; techbo...@dpdk.org > > Subject: Re: [PATCH v1] doc: deprecation notice to add callback data to > > rte_event_fp_ops > > > > On 7/17/2023 12:24 PM, Sivaprasad Tummala wrote: > > > Deprecation notice to add "rte_eventdev_port_data" field to > > > ``rte_event_fp_ops`` for callback support. > > > > > > Signed-off-by: Sivaprasad Tummala > > > --- > > > doc/guides/rel_notes/deprecation.rst | 7 +++ > > > 1 file changed, 7 insertions(+) > > > > > > diff --git a/doc/guides/rel_notes/deprecation.rst > > > b/doc/guides/rel_notes/deprecation.rst > > > index fb771a0305..057f97ce5a 100644 > > > --- a/doc/guides/rel_notes/deprecation.rst > > > +++ b/doc/guides/rel_notes/deprecation.rst > > > @@ -130,6 +130,13 @@ Deprecation Notices > > >``rte_cryptodev_get_auth_algo_string``, > > ``rte_cryptodev_get_aead_algo_string`` and > > >``rte_cryptodev_asym_get_xform_string`` respectively. > > > > > > +* eventdev: The struct rte_event_fp_ops will be updated with a new > > > +element > > > + rte_eventdev_port_data to support optional callbacks in DPDK 23.11. > > > + rte_eventdev_port_data is used to hold callbacks registered > > > +optionally > > > + per event device port and associated callback data. By adding > > > +rte_eventdev_port_data > > > + to rte_event_fp_ops, allows to fetch this data for fastpath > > > +eventdev inline functions > > > + in advance. This changes the size of rte_event_fp_ops and result in ABI > > change. > > > + > > > * security: Hide structures ``rte_security_ops`` and ``rte_security_ctx`` > > >as these are internal to DPDK library and drivers. > > > > > > > +techboard, > > > > Request for review/ack, patch is to extend eventdev to support callbacks > per > > packet. > Acked-by: Hemant Agrawal Acked-by: Pavan Nikhilesh
Re: [dpdk-dev] [PATCH v1] doc: process for new library approval in principle
> > Based on techboard meeting[1] action item, defining the process for a > > new library approval in principle. > > > > [1] > > https://mails.dpdk.org/archives/dev/2023-January/260035.html > > > > Signed-off-by: Jerin Jacob > > --- > > RFC..v1: > > - Fix the review comments by Konstantin, Keven, Thomas at > > http://patches.dpdk.org/project/dpdk/patch/20230213092616.3589932-1-jer...@marvell.com/ [...] > > +Process for new library approval in principle > > += > > + > > +Rationale > > +- > > + > > +Adding a new library to DPDK with proper RFC and then full patch-sets is > > significant work. > > +In order to save effort, developers will get an early approval in > > principle, or early feedback in > > +case the library is not suitable for various reasons. > > + > > +Process > > +--- > > + > > +#. When a contributor would like to add a new library to DPDK code base, > > the contributor must send > > + the following items to DPDK mailing list for technical board > > approval-in-principle. > > + > > + * Purpose of the library. > > + * Scope of work: outline the various additional tasks planned for this > > library, such as > > + developing new test applications, adding new drivers, and updating > > existing applications. > > + * Expected usage models of the library. > > + * Any licensing constraints. > > + * Justification for adding to DPDK. > > + * Any other implementations of the same functionality in other > > libraries/projects and how this > > + version differs. > > + * Public API specification header file as RFC. > > + > > + * Optional and good to have. > > + * Technical board may additionally request this collateral if > > needed to get more clarity > > + on scope and purpose. > > + * Any new library dependencies to DPDK. > > + > > +#. Technical board to schedule discussion on this in upcoming technical > > board meeting along with > > + author. Based on the technical board schedule and/or author > > availability, technical board may > > + need a maximum of **five** technical board meeting slots. > > + > > +#. Based on mailing list and technical board meeting discussions, > > technical board to vote and share > > + the decision in the mailing list. The decision outcome can be any of > > the following. > > + > > + * Approved in principal > > + * Not approved > > + * Further information needed > > + > > +#. Once technical board approves the library in principle, it is safe to > > start working on the > > + implementation. However, the patches will need to meet the usual > > quality criteria in order to be > > + effectively accepted. > > > Looks reasonable to me, and it is good to start to document the process > anyway, we can tweak it later if required, hence: > > Acked-by: Ferruh Yigit I prefer the new page having a broader scope: adding a new library. So I make this new doc as a chapter of a new page "Adding a new library". Applied, thanks. Later we could add some tips for new libraries: what to copy elsewhere, what to not forget (maintainer, doc, test, doc indexes, etc).
[PATCH] net/mana: add support to update MTU
From: Long Li
Add support for updating MTU for MANA. MTU is updated in kernel through
socket interface.
Signed-off-by: Long Li
---
doc/guides/nics/features/mana.ini | 1 +
drivers/net/mana/mana.c | 96 ++-
drivers/net/mana/mana.h | 2 +-
3 files changed, 96 insertions(+), 3 deletions(-)
diff --git a/doc/guides/nics/features/mana.ini
b/doc/guides/nics/features/mana.ini
index e69bf4af15..42fd3327d2 100644
--- a/doc/guides/nics/features/mana.ini
+++ b/doc/guides/nics/features/mana.ini
@@ -13,6 +13,7 @@ RSS hash = Y
L3 checksum offload = Y
L4 checksum offload = Y
Basic stats = Y
+MTU update = Y
Multiprocess aware = Y
Linux= Y
x86-64 = Y
diff --git a/drivers/net/mana/mana.c b/drivers/net/mana/mana.c
index 7630118d4f..f1fdcf426a 100644
--- a/drivers/net/mana/mana.c
+++ b/drivers/net/mana/mana.c
@@ -6,6 +6,8 @@
#include
#include
#include
+#include
+#include
#include
#include
@@ -286,11 +288,12 @@ mana_dev_info_get(struct rte_eth_dev *dev,
{
struct mana_priv *priv = dev->data->dev_private;
- dev_info->max_mtu = RTE_ETHER_MTU;
+ dev_info->min_mtu = RTE_ETHER_MIN_MTU;
+ dev_info->max_mtu = MANA_MAX_MTU;
/* RX params */
dev_info->min_rx_bufsize = MIN_RX_BUF_SIZE;
- dev_info->max_rx_pktlen = MAX_FRAME_SIZE;
+ dev_info->max_rx_pktlen = MANA_MAX_MTU + RTE_ETHER_HDR_LEN;
dev_info->max_rx_queues = priv->max_rx_queues;
dev_info->max_tx_queues = priv->max_tx_queues;
@@ -700,6 +703,94 @@ mana_dev_stats_reset(struct rte_eth_dev *dev __rte_unused)
return 0;
}
+static int
+mana_get_ifname(const struct mana_priv *priv, char (*ifname)[IF_NAMESIZE])
+{
+ int ret;
+ DIR *dir;
+ struct dirent *dent;
+
+ MANA_MKSTR(dirpath, "%s/device/net", priv->ib_ctx->device->ibdev_path);
+
+ dir = opendir(dirpath);
+ if (dir == NULL)
+ return -ENODEV;
+
+ while ((dent = readdir(dir)) != NULL) {
+ char *name = dent->d_name;
+ FILE *file;
+ struct rte_ether_addr addr;
+ char *mac = NULL;
+
+ if ((name[0] == '.') &&
+ ((name[1] == '\0') ||
+((name[1] == '.') && (name[2] == '\0'
+ continue;
+
+ MANA_MKSTR(path, "%s/%s/address", dirpath, name);
+
+ file = fopen(path, "r");
+ if (!file) {
+ ret = -ENODEV;
+ break;
+ }
+
+ ret = fscanf(file, "%ms", &mac);
+ fclose(file);
+
+ if (ret <= 0) {
+ ret = -EINVAL;
+ break;
+ }
+
+ ret = rte_ether_unformat_addr(mac, &addr);
+ free(mac);
+ if (ret)
+ break;
+
+ if (rte_is_same_ether_addr(&addr, priv->dev_data->mac_addrs)) {
+ strlcpy(*ifname, name, sizeof(*ifname));
+ ret = 0;
+ break;
+ }
+ }
+
+ closedir(dir);
+ return ret;
+}
+
+static int
+mana_ifreq(const struct mana_priv *priv, int req, struct ifreq *ifr)
+{
+ int sock, ret;
+
+ sock = socket(PF_INET, SOCK_DGRAM, IPPROTO_IP);
+ if (sock == -1)
+ return -errno;
+
+ ret = mana_get_ifname(priv, &ifr->ifr_name);
+ if (ret) {
+ close(sock);
+ return ret;
+ }
+
+ if (ioctl(sock, req, ifr) == -1)
+ ret = -errno;
+
+ close(sock);
+
+ return ret;
+}
+
+static int
+mana_mtu_set(struct rte_eth_dev *dev, uint16_t mtu)
+{
+ struct mana_priv *priv = dev->data->dev_private;
+ struct ifreq request = { .ifr_mtu = mtu, };
+
+ return mana_ifreq(priv, SIOCSIFMTU, &request);
+}
+
static const struct eth_dev_ops mana_dev_ops = {
.dev_configure = mana_dev_configure,
.dev_start = mana_dev_start,
@@ -720,6 +811,7 @@ static const struct eth_dev_ops mana_dev_ops = {
.link_update= mana_dev_link_update,
.stats_get = mana_dev_stats_get,
.stats_reset= mana_dev_stats_reset,
+ .mtu_set= mana_mtu_set,
};
static const struct eth_dev_ops mana_dev_secondary_ops = {
diff --git a/drivers/net/mana/mana.h b/drivers/net/mana/mana.h
index 5801491d75..ee8ea4aee3 100644
--- a/drivers/net/mana/mana.h
+++ b/drivers/net/mana/mana.h
@@ -16,8 +16,8 @@ struct mana_shared_data {
unsigned int secondary_cnt;
};
+#define MANA_MAX_MTU 9000
#define MIN_RX_BUF_SIZE1024
-#define MAX_FRAME_SIZE RTE_ETHER_MAX_LEN
#define MANA_MAX_MAC_ADDR 1
#define MANA_DEV_RX_OFFLOAD_SUPPORT ( \
--
2.34.1
[PATCH] net/mana: use %m for fscanf to read mac address
From: Long Li
Use %m through fscanf to allocate mac dynamically is safer than using
mac[20], this guarantees there is no overflow on mac[].
Signed-off-by: Long Li
---
drivers/net/mana/mana.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/net/mana/mana.c b/drivers/net/mana/mana.c
index f1fdcf426a..28d8f5b23e 100644
--- a/drivers/net/mana/mana.c
+++ b/drivers/net/mana/mana.c
@@ -914,7 +914,6 @@ get_port_mac(struct ibv_device *device, unsigned int port,
DIR *dir;
struct dirent *dent;
unsigned int dev_port;
- char mac[20];
MANA_MKSTR(path, "%s/device/net", device->ibdev_path);
@@ -924,6 +923,7 @@ get_port_mac(struct ibv_device *device, unsigned int port,
while ((dent = readdir(dir))) {
char *name = dent->d_name;
+ char *mac = NULL;
MANA_MKSTR(port_path, "%s/%s/dev_port", path, name);
@@ -951,7 +951,7 @@ get_port_mac(struct ibv_device *device, unsigned int port,
if (!file)
continue;
- ret = fscanf(file, "%s", mac);
+ ret = fscanf(file, "%ms", &mac);
fclose(file);
if (ret < 0)
@@ -960,6 +960,8 @@ get_port_mac(struct ibv_device *device, unsigned int port,
ret = rte_ether_unformat_addr(mac, addr);
if (ret)
DRV_LOG(ERR, "unrecognized mac addr %s", mac);
+
+ free(mac);
break;
}
}
--
2.34.1
RE: [PATCH] tap: fix build of tap_bpf_program
> Subject: Re: [PATCH] tap: fix build of tap_bpf_program
>
> On 7/20/2023 8:45 AM, Ferruh Yigit wrote:
> > On 7/19/2023 5:12 PM, Stephen Hemminger wrote:
> >> On Wed, 19 Jul 2023 11:03:36 +0100
> >> Ferruh Yigit wrote:
> >>
> >>> On 7/19/2023 11:00 AM, Ferruh Yigit wrote:
> On 7/17/2023 8:15 PM, Stephen Hemminger wrote:
> > The tap_bpf_program.c is not built as part of normal DPDK EAL
> > environment. It is intended to be built standalone and does not
> > use rte_common.h.
> >
> > This reverts the related change from commit ef5baf3486e0 ("replace
> > packed attributes")
> >
> > Note: this patch will cause expected warnings from checkpatch
> > because the code involved is not used directly in DPDK environment.
> >
> > Signed-off-by: Stephen Hemminger
> >
>
> Agree, this seems done by mistake as part of batch update,
>
> Acked-by: Ferruh Yigit
>
>
> But I can't update the bpf file at all, if I am not missing
> something I
> >>>
> >>> * I can't *compile* the bpf file ...
> >>>
> am not sure if we should get just this update or have a
> patch/patchset that fixes the build.
>
> @Ophir, how the bpf file is compiled? And did you test it recently?
>
> I am using command from the documentation:
> `clang -O2 -emit-llvm -c tap_bpf_program.c -o - | llc -march=bpf
> -filetype=obj -o tap_bpf_program.o`
> >>
> >> It looks like this won't work because it was expecting to be able to
> >> find header files from older version of iproute2. These are not
> >> distributed, and the change to support libbpf in iproute2 makes the
> >> current versions not work.
> >>
> >> As a stopgap, will look back in history and see what version of
> >> header files will at least get a working build.
> >>
> >> From there, need to replace how the conversion of .o to array works.
> >> Would prefer to use dlopen() to read the ELF file rather than
> >> expecting developers to hack together their own tools.
> >>
> >> Not sure how much effort is really needed here. This is only being
> >> used for the case of rte_flow with multiq RSS. Probably, no one ever
> >> used it.
> >>
> >
> > Should we remove the file, instead of fixing '__rte_packed'?
> >
>
> +Long, and af_xdp maintainers,
>
> @Long, do you know if this bfp code is still in use somewhere, if so is the
> user
> interested in fixing/maintaining the code?
I haven't seen usage in the support cases we have handled. Given support cases
represent very small percent of actual usage, I suspect it's still being used.
>
>
> @Ciara, @Qi, do you see any benefit to keep/extend this kind of bfp file
> usage?
> Do you think is this something to invest more?
[PATCH] doc: announce changes to event device structures
From: Pavan Nikhilesh The structures ``rte_event_dev_info``, ``rte_event_fp_ops`` will be modified to add new elements to support link profiles. A new field ``max_profiles_per_port`` will be added to ``rte_event_dev_info`` and ``switch_profile`` will be added to ``rte_event_fp_ops``. Two new experimental APIs will be added, one to associate one to associate an set of event queues with a profile which can be linked to a event port and another to switch the profile which would affect the next dequeue call. Signed-off-by: Pavan Nikhilesh --- doc/guides/rel_notes/deprecation.rst | 8 1 file changed, 8 insertions(+) diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst index fb771a0305..2b1fcf52ca 100644 --- a/doc/guides/rel_notes/deprecation.rst +++ b/doc/guides/rel_notes/deprecation.rst @@ -161,3 +161,11 @@ Deprecation Notices The new port library API (functions rte_swx_port_*) will gradually transition from experimental to stable status starting with DPDK 23.07 release. + +* eventdev: The structures ``rte_event_dev_info``, ``rte_event_fp_ops`` will be + modified to add new elements to support link profiles.A new field + ``max_profiles_per_port`` will be added to ``rte_event_dev_info`` and + ``switch_profile`` will be added to ``rte_event_fp_ops``. + Two new experimental APIs will be added, one to associate an set of event + queues with a profile which can be linked to a event port and an other to + switch the profile which would affect the next dequeue call. -- 2.25.1
RE: [PATCH] doc/dmadevs: add note clarifying naming of idxd devices
[AMD Official Use Only - General] > -Original Message- > From: Bruce Richardson > Sent: Tuesday, July 25, 2023 9:49 PM > To: dev@dpdk.org > Cc: Varghese, Vipin > Subject: Re: [PATCH] doc/dmadevs: add note clarifying naming of idxd devices > > Caution: This message originated from an External Source. Use proper > caution when opening attachments, clicking links, or responding. > > > On Tue, Jul 25, 2023 at 05:16:29PM +0100, Bruce Richardson wrote: > > Since the test-dma-perf application identifies devices by name, > > include in the idxd driver documentation a note on device naming when > vfio-pci. > > See also discussion in bugzilla[1]. > > > > [1] https://bugs.dpdk.org/show_bug.cgi?id=1268 > > > > Signed-off-by: Bruce Richardson > > --- > Note, although I reference bugzilla here, I don't consider this a bugfix, so > I've > not included a fixes tag and official bugzilla id etc. It's instead a note > clarifying > the expected behaviour. App/dma-perf got integrated into DPDK via `https://patches.dpdk.org/project/dpdk/patch/20230629131455.52732-1-cheng1.ji...@intel.com/`. The expectation is that, it is tried and tested for hardware dma, sw skeleton dma and cpu memcpy. Happy to acknowledge the change as it helps the DPDK community. Acked-by: Vipin Varghese > > /Bruce
[PATCH v2] Add support for IBM Z s390x
Minimal changes to drivers and app to support the IBM s390x.
Signed-off-by: David Miller
Reviewed-by: Mathew S Thoennes
---
app/test-acl/main.c | 4 +
app/test/test_acl.c | 1 +
app/test/test_atomic.c | 7 +-
app/test/test_cmdline_ipaddr.c | 12 +-
app/test/test_cmdline_num.c | 110
app/test/test_hash_functions.c | 29 +
app/test/test_xmmt_ops.h | 14 +
buildtools/pmdinfogen.py | 11 +-
config/meson.build | 2 +
config/s390x/meson.build | 51 ++
config/s390x/s390x_linux_clang_ubuntu| 19 +
doc/guides/nics/features/i40e.ini| 1 +
drivers/common/mlx5/mlx5_common.h| 9 +
drivers/net/i40e/i40e_rxtx_vec_s390x.c | 630 +++
drivers/net/i40e/meson.build | 2 +
drivers/net/ixgbe/ixgbe_rxtx.c | 8 +-
drivers/net/memif/rte_eth_memif.h| 2 +
drivers/net/mlx5/mlx5_rx.c | 24 +-
drivers/net/octeontx/base/octeontx_pki_var.h | 6 +
examples/l3fwd/l3fwd_em.c| 8 +
examples/l3fwd/l3fwd_lpm_s390x.h | 137
examples/l3fwd/l3fwd_s390x.h | 261
lib/acl/acl_bld.c| 3 +
lib/acl/acl_gen.c| 9 +
lib/acl/acl_run_scalar.c | 8 +
lib/acl/rte_acl.c| 27 +
lib/acl/rte_acl.h| 5 +-
lib/eal/s390x/include/meson.build| 16 +
lib/eal/s390x/include/rte_atomic.h | 44 ++
lib/eal/s390x/include/rte_byteorder.h| 43 ++
lib/eal/s390x/include/rte_cpuflags.h | 41 ++
lib/eal/s390x/include/rte_cycles.h | 44 ++
lib/eal/s390x/include/rte_io.h | 184 ++
lib/eal/s390x/include/rte_mcslock.h | 18 +
lib/eal/s390x/include/rte_memcpy.h | 55 ++
lib/eal/s390x/include/rte_pause.h| 22 +
lib/eal/s390x/include/rte_power_intrinsics.h | 20 +
lib/eal/s390x/include/rte_prefetch.h | 46 ++
lib/eal/s390x/include/rte_rwlock.h | 42 ++
lib/eal/s390x/include/rte_spinlock.h | 85 +++
lib/eal/s390x/include/rte_ticketlock.h | 18 +
lib/eal/s390x/include/rte_vect.h | 35 ++
lib/eal/s390x/meson.build| 16 +
lib/eal/s390x/rte_cpuflags.c | 91 +++
lib/eal/s390x/rte_cycles.c | 11 +
lib/eal/s390x/rte_hypervisor.c | 11 +
lib/eal/s390x/rte_power_intrinsics.c | 51 ++
lib/hash/rte_fbk_hash.h | 7 +
lib/lpm/meson.build | 1 +
lib/lpm/rte_lpm.h| 2 +
lib/lpm/rte_lpm6.c | 18 +
lib/lpm/rte_lpm_s390x.h | 130
meson.build | 2 +
53 files changed, 2439 insertions(+), 14 deletions(-)
create mode 100644 config/s390x/meson.build
create mode 100644 config/s390x/s390x_linux_clang_ubuntu
create mode 100644 drivers/net/i40e/i40e_rxtx_vec_s390x.c
create mode 100644 examples/l3fwd/l3fwd_lpm_s390x.h
create mode 100644 examples/l3fwd/l3fwd_s390x.h
create mode 100644 lib/eal/s390x/include/meson.build
create mode 100644 lib/eal/s390x/include/rte_atomic.h
create mode 100644 lib/eal/s390x/include/rte_byteorder.h
create mode 100644 lib/eal/s390x/include/rte_cpuflags.h
create mode 100644 lib/eal/s390x/include/rte_cycles.h
create mode 100644 lib/eal/s390x/include/rte_io.h
create mode 100644 lib/eal/s390x/include/rte_mcslock.h
create mode 100644 lib/eal/s390x/include/rte_memcpy.h
create mode 100644 lib/eal/s390x/include/rte_pause.h
create mode 100644 lib/eal/s390x/include/rte_power_intrinsics.h
create mode 100644 lib/eal/s390x/include/rte_prefetch.h
create mode 100644 lib/eal/s390x/include/rte_rwlock.h
create mode 100644 lib/eal/s390x/include/rte_spinlock.h
create mode 100644 lib/eal/s390x/include/rte_ticketlock.h
create mode 100644 lib/eal/s390x/include/rte_vect.h
create mode 100644 lib/eal/s390x/meson.build
create mode 100644 lib/eal/s390x/rte_cpuflags.c
create mode 100644 lib/eal/s390x/rte_cycles.c
create mode 100644 lib/eal/s390x/rte_hypervisor.c
create mode 100644 lib/eal/s390x/rte_power_intrinsics.c
create mode 100644 lib/lpm/rte_lpm_s390x.h
diff --git a/app/test-acl/main.c b/app/test-acl/main.c
index 41ce83db08..68bde76e52 100644
--- a/app/test-acl/main.c
+++ b/app/test-acl/main.c
@@ -89,6 +89,10 @@ static const struct acl_alg acl_alg[] = {
.name = "altivec",
.alg = RTE_ACL_CLASSIFY_ALTIVEC,
},
+ {
+ .name = "s390x",
+ .alg = RTE_ACL_CLASSIFY_S390X,
+ },
{
.name = "avx512x16",
.alg = RTE_ACL_CLASSIFY_AVX512X16
[PATCH v3] Add support for IBM Z s390x
Minimal changes to drivers and app to support the IBM s390x.
Signed-off-by: David Miller
Reviewed-by: Mathew S Thoennes
---
app/test-acl/main.c | 4 +
app/test/test_acl.c | 1 +
app/test/test_atomic.c | 7 +-
app/test/test_cmdline_ipaddr.c | 12 +-
app/test/test_cmdline_num.c | 110
app/test/test_hash_functions.c | 29 +
app/test/test_xmmt_ops.h | 14 +
buildtools/pmdinfogen.py | 11 +-
config/meson.build | 2 +
config/s390x/meson.build | 51 ++
config/s390x/s390x_linux_clang_ubuntu| 19 +
doc/guides/nics/features/i40e.ini| 1 +
drivers/common/mlx5/mlx5_common.h| 9 +
drivers/net/i40e/i40e_rxtx_vec_s390x.c | 630 +++
drivers/net/i40e/meson.build | 2 +
drivers/net/ixgbe/ixgbe_rxtx.c | 8 +-
drivers/net/memif/rte_eth_memif.h| 2 +
drivers/net/mlx5/mlx5_rx.c | 24 +-
drivers/net/octeontx/base/octeontx_pki_var.h | 6 +
examples/l3fwd/l3fwd_em.c| 8 +
examples/l3fwd/l3fwd_lpm_s390x.h | 137
examples/l3fwd/l3fwd_s390x.h | 261
lib/acl/acl_bld.c| 3 +
lib/acl/acl_gen.c| 9 +
lib/acl/acl_run_scalar.c | 8 +
lib/acl/rte_acl.c| 27 +
lib/acl/rte_acl.h| 5 +-
lib/eal/s390x/include/meson.build| 16 +
lib/eal/s390x/include/rte_atomic.h | 44 ++
lib/eal/s390x/include/rte_byteorder.h| 43 ++
lib/eal/s390x/include/rte_cpuflags.h | 41 ++
lib/eal/s390x/include/rte_cycles.h | 44 ++
lib/eal/s390x/include/rte_io.h | 184 ++
lib/eal/s390x/include/rte_mcslock.h | 18 +
lib/eal/s390x/include/rte_memcpy.h | 55 ++
lib/eal/s390x/include/rte_pause.h| 22 +
lib/eal/s390x/include/rte_power_intrinsics.h | 20 +
lib/eal/s390x/include/rte_prefetch.h | 46 ++
lib/eal/s390x/include/rte_rwlock.h | 42 ++
lib/eal/s390x/include/rte_spinlock.h | 85 +++
lib/eal/s390x/include/rte_ticketlock.h | 18 +
lib/eal/s390x/include/rte_vect.h | 35 ++
lib/eal/s390x/meson.build| 16 +
lib/eal/s390x/rte_cpuflags.c | 91 +++
lib/eal/s390x/rte_cycles.c | 11 +
lib/eal/s390x/rte_hypervisor.c | 11 +
lib/eal/s390x/rte_power_intrinsics.c | 51 ++
lib/hash/rte_fbk_hash.h | 7 +
lib/lpm/meson.build | 1 +
lib/lpm/rte_lpm.h| 2 +
lib/lpm/rte_lpm6.c | 18 +
lib/lpm/rte_lpm_s390x.h | 130
meson.build | 2 +
53 files changed, 2439 insertions(+), 14 deletions(-)
create mode 100644 config/s390x/meson.build
create mode 100644 config/s390x/s390x_linux_clang_ubuntu
create mode 100644 drivers/net/i40e/i40e_rxtx_vec_s390x.c
create mode 100644 examples/l3fwd/l3fwd_lpm_s390x.h
create mode 100644 examples/l3fwd/l3fwd_s390x.h
create mode 100644 lib/eal/s390x/include/meson.build
create mode 100644 lib/eal/s390x/include/rte_atomic.h
create mode 100644 lib/eal/s390x/include/rte_byteorder.h
create mode 100644 lib/eal/s390x/include/rte_cpuflags.h
create mode 100644 lib/eal/s390x/include/rte_cycles.h
create mode 100644 lib/eal/s390x/include/rte_io.h
create mode 100644 lib/eal/s390x/include/rte_mcslock.h
create mode 100644 lib/eal/s390x/include/rte_memcpy.h
create mode 100644 lib/eal/s390x/include/rte_pause.h
create mode 100644 lib/eal/s390x/include/rte_power_intrinsics.h
create mode 100644 lib/eal/s390x/include/rte_prefetch.h
create mode 100644 lib/eal/s390x/include/rte_rwlock.h
create mode 100644 lib/eal/s390x/include/rte_spinlock.h
create mode 100644 lib/eal/s390x/include/rte_ticketlock.h
create mode 100644 lib/eal/s390x/include/rte_vect.h
create mode 100644 lib/eal/s390x/meson.build
create mode 100644 lib/eal/s390x/rte_cpuflags.c
create mode 100644 lib/eal/s390x/rte_cycles.c
create mode 100644 lib/eal/s390x/rte_hypervisor.c
create mode 100644 lib/eal/s390x/rte_power_intrinsics.c
create mode 100644 lib/lpm/rte_lpm_s390x.h
diff --git a/app/test-acl/main.c b/app/test-acl/main.c
index 41ce83db08..68bde76e52 100644
--- a/app/test-acl/main.c
+++ b/app/test-acl/main.c
@@ -89,6 +89,10 @@ static const struct acl_alg acl_alg[] = {
.name = "altivec",
.alg = RTE_ACL_CLASSIFY_ALTIVEC,
},
+ {
+ .name = "s390x",
+ .alg = RTE_ACL_CLASSIFY_S390X,
+ },
{
.name = "avx512x16",
.alg = RTE_ACL_CLASSIFY_AVX512X16
[PATCH v2] app/test:subprocess synchronization of parameters
In meson_test, because the child process does not synchronize
the NIC startup parameters of the parent process at startup,
it uses all NICs bound by vfio as startup parameters by default,
and an exception occurs in the subsequent hugefile check,
causing the test to fail. Synchronize the NIC startup parameters
of the parent process to the child process to solve this problem.
Fixes: af75078fece3 ("first public release")
Cc: sta...@dpdk.org
Signed-off-by: Kaisen You
---
Changes since v1:
- change the patch title to modify the way child
processes get NIC parameters
---
app/test/process.h | 27 +++
1 file changed, 23 insertions(+), 4 deletions(-)
diff --git a/app/test/process.h b/app/test/process.h
index 1f073b9c5c..76a1646b24 100644
--- a/app/test/process.h
+++ b/app/test/process.h
@@ -15,9 +15,12 @@
#include /* strerror */
#include /* readlink */
#include
+#include "../../drivers/bus/pci/private.h"
#include /* strlcpy */
+#define MAX_EXTRA_ARGS 32
+#define PCI_PRI_FMT "%.4" PRIx32 ":%.2" PRIx8 ":%.2" PRIx8 ".%" PRIx8
#ifdef RTE_EXEC_ENV_FREEBSD
#define self "curproc"
#define exe "file"
@@ -33,7 +36,6 @@ extern void *send_pkts(void *empty);
extern uint16_t flag_for_send_pkts;
#endif
#endif
-
/*
* launches a second copy of the test process using the given argv parameters,
* which should include argv[0] as the process name. To identify in the
@@ -44,9 +46,13 @@ static inline int
process_dup(const char *const argv[], int numargs, const char *env_value)
{
int num;
- char *argv_cpy[numargs + 1];
- int i, status;
+ char *argv_cpy[MAX_EXTRA_ARGS];
+ int i, status, s;
char path[32];
+ struct rte_pci_device *dev = NULL;
+ char type[MAX_EXTRA_ARGS];
+ char *argv_str[MAX_EXTRA_ARGS];
+ char str_1[] = "-a";
#ifdef RTE_LIB_PDUMP
#ifdef RTE_NET_RING
pthread_t thread;
@@ -113,10 +119,23 @@ process_dup(const char *const argv[], int numargs, const
char *env_value)
closedir(dir);
}
#endif
+ s = -1;
+ argv_str[0] = strdup(str_1);
+ FOREACH_DEVICE_ON_PCIBUS(dev) {
+ s = s + 2;
+ sprintf(type, PCI_PRI_FMT, dev->addr.domain,
+ dev->addr.bus, dev->addr.devid, dev->addr.function);
+ argv_str[s - 1] = strdup(str_1);
+ argv_str[s] = strdup(type);
+ }
+ for (i = 0; i < s + 1; i++)
+ argv_cpy[num + i] = strdup(argv_str[i]);
+
printf("Running binary with argv[]:");
- for (i = 0; i < num; i++)
+ for (i = 0; i < num + s + 1; i++)
printf("'%s' ", argv_cpy[i]);
printf("\n");
+ argv_cpy[numargs + s + 1] = NULL;
fflush(stdout);
/* set the environment variable */
--
2.25.1
DPDK Tech Board Meeting - Tomorrow, Wed. Jul. 26, 2023 - 8am Pacific/11am Eastern
Good evening, Tomorrow DPDK will hold its biweekly tech board meeting. A read-only agenda can be accessed here: https://annuel.framapad.org/p/r.0c3cc4d1e011214183872a98f6b5c7db And as always, the login: https://meet.jit.si/dpdk We look forward to seeing you there. Thanks, Nathan Nathan C. Southern, Project Coordinator Data Plane Development Kit The Linux Foundation 248.835.4812 (mobile) nsouth...@linuxfoundation.org
[PATCH v2 1/1] app/test: resolve mbuf_test application failure
when RTE_ENABLE_ASSERT is defined test_mbuf application is
failing because we are trying to attach extbuf to a cloned
buffer to which external mbuf is already attached.To make
test_mbuf pass CI we have updated ol_flags. This patch fixes
the same.
Signed-off-by: Rakesh Kudurumalla
---
v2 : Addressed comments by removing extbuf call
as mbuf is already attached
app/test/test_mbuf.c | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/app/test/test_mbuf.c b/app/test/test_mbuf.c
index efac01806b..722e1ef624 100644
--- a/app/test/test_mbuf.c
+++ b/app/test/test_mbuf.c
@@ -2345,16 +2345,13 @@ test_pktmbuf_ext_shinfo_init_helper(struct rte_mempool
*pktmbuf_pool)
GOTO_FAIL("%s: External buffer is not attached to mbuf\n",
__func__);
- /* allocate one more mbuf */
+ /* allocate one more mbuf, it is attached to the same external buffer */
clone = rte_pktmbuf_clone(m, pktmbuf_pool);
if (clone == NULL)
GOTO_FAIL("%s: mbuf clone allocation failed!\n", __func__);
if (rte_pktmbuf_pkt_len(clone) != 0)
GOTO_FAIL("%s: Bad packet length\n", __func__);
- /* attach the same external buffer to the cloned mbuf */
- rte_pktmbuf_attach_extbuf(clone, ext_buf_addr, buf_iova, buf_len,
- ret_shinfo);
if (clone->ol_flags != RTE_MBUF_F_EXTERNAL)
GOTO_FAIL("%s: External buffer is not attached to mbuf\n",
__func__);
--
2.25.1
