The dispatcher tests failed to transfer the impl_opaque rte_event
field between the dequeued and enqueued event, in violation with the
Eventdev API contract.
Fixes: ecca8a0be606 ("lib: introduce dispatcher library")
Cc: sta...@dpdk.org
Signed-off-by: Mattias Rönnblom
---
app/test/test_dispatche
On Wed, 11 Dec 2024 10:00:38 +0100
David Marchand wrote:
> On Tue, Dec 10, 2024 at 6:00 PM Stephen Hemminger
> wrote:
> >
> > On Tue, 10 Dec 2024 10:10:39 +0100
> > David Marchand wrote:
> >
> > > +no_license_list=\
> > > +':^.git* :^.mailmap :^.ci/* :^README :^MAINTAINERS :^VERSION
> > > :^
On Mon, Nov 25, 2024 at 10:47 AM Patrick Robb wrote:
> Hello,
>
> I have a couple reminders/updates for the schedule of the upcoming DPDK CI
> Testing meetings.
>
> 1. The meeting which was scheduled to happen this Thursday, November 28,
> is cancelled due to the American Thanksgiving Holiday. To
11/12/2024 15:55, Stephen Hemminger:
> On Wed, 11 Dec 2024 10:00:38 +0100
> David Marchand wrote:
>
> > On Tue, Dec 10, 2024 at 6:00 PM Stephen Hemminger
> > wrote:
> > >
> > > On Tue, 10 Dec 2024 10:10:39 +0100
> > > David Marchand wrote:
> > >
> > > > +no_license_list=\
> > > > +':^.git* :^
Hi Yanghang,
Thanks for the quick verification and response!
Best Regards,
Xueming
From: Yanghang Liu
Sent: Wednesday, December 11, 2024 7:24 PM
To: Xueming Li
Cc: sta...@dpdk.org ; dev@dpdk.org ; Abhishek
Marathe ; Ali Alnubani ;
David Christensen ; Hemant A
On Wed, 11 Dec 2024 11:34:39 +
Konstantin Ananyev wrote:
> > This is first draft of new simplified TAP device that uses
> > the Linux kernel ioring API to provide a read/write ring
> > with kernel.
> >
> > This is split from tap device because there are so many
> > unnecessary things in exis
On Tue, 10 Dec 2024 13:53:19 +0800
Junlong Wang wrote:
> (np)network Processor initialize resources in host,
> and initialize a channel for some tables insert/get/del.
>
> Signed-off-by: Junlong Wang
This mostly looks good, just some small stuff.
> ---
> drivers/net/zxdh/meson.build | 1
On Tue, Dec 10, 2024 at 07:13:21PM -0800, Stephen Hemminger wrote:
> On Tue, 10 Dec 2024 18:05:46 -0800
> Andre Muezerie wrote:
>
> > Add "do { } while (0)" to macros used to remove logging calls, to
> > ensure there's no code structure change when enabling/disabling
> > logging.
> >
> > Signed-
On 09/12/2024 03:44, Yanghang Liu wrote:
> I tested below 18 scenarios on RHEL 9.2 and didn't find any new dpdk issues.
>
Thanks Yanghang. I will add a note about the validation to the release
notes.
Kevin.
>- VM with device assignment(PF) throughput testing(1G hugepage size):
>PASS
>
Add basic driver initialization, documentation, and device creation
and basic documentation.
Signed-off-by: Stephen Hemminger
---
doc/guides/nics/features/ioring.ini | 9 +
doc/guides/nics/index.rst | 1 +
doc/guides/nics/ioring.rst | 66 +++
drivers/net/ioring/meson.
Add hooks to set kernel link up/down and report state.
Signed-off-by: Stephen Hemminger
---
doc/guides/nics/features/ioring.ini | 1 +
drivers/net/ioring/rte_eth_ioring.c | 84 +
2 files changed, 85 insertions(+)
diff --git a/doc/guides/nics/features/ioring.ini
b/d
These internal ops, just force changes to kernel visible net device.
Signed-off-by: Stephen Hemminger
---
doc/guides/nics/features/ioring.ini | 3 ++
drivers/net/ioring/rte_eth_ioring.c | 69 +
2 files changed, 72 insertions(+)
diff --git a/doc/guides/nics/features/
This is initial work of new simplified TAP device that uses
the Linux kernel ioring API to provide a read/write ring
with kernel.
This is split from tap device because there are so many
unnecessary things in existing tap, and supporting ioring is
better without ifdefs etc. The default name of the
Add start, stop, configure and info functions.
Signed-off-by: Stephen Hemminger
---
drivers/net/ioring/rte_eth_ioring.c | 72 ++---
1 file changed, 66 insertions(+), 6 deletions(-)
diff --git a/drivers/net/ioring/rte_eth_ioring.c
b/drivers/net/ioring/rte_eth_ioring.c
in
Use io_uring to read and write from TAP device.
Signed-off-by: Stephen Hemminger
---
drivers/net/ioring/rte_eth_ioring.c | 365 +++-
1 file changed, 364 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ioring/rte_eth_ioring.c
b/drivers/net/ioring/rte_eth_ioring.c
i
Add support for communicating fd's from primary to secondary.
Signed-off-by: Stephen Hemminger
---
doc/guides/nics/features/ioring.ini | 1 +
drivers/net/ioring/rte_eth_ioring.c | 136 +++-
2 files changed, 135 insertions(+), 2 deletions(-)
diff --git a/doc/guides/nics
Add support for basic statistics
Signed-off-by: Stephen Hemminger
---
doc/guides/nics/features/ioring.ini | 2 +
drivers/net/ioring/rte_eth_ioring.c | 57 +
2 files changed, 59 insertions(+)
diff --git a/doc/guides/nics/features/ioring.ini
b/doc/guides/nics/feature
Add support for VLAN insert and stripping.
Signed-off-by: Stephen Hemminger
---
drivers/net/ioring/rte_eth_ioring.c | 45 +++--
1 file changed, 43 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ioring/rte_eth_ioring.c
b/drivers/net/ioring/rte_eth_ioring.c
index
https://bugs.dpdk.org/show_bug.cgi?id=1595
Bug ID: 1595
Summary: failed to compile DPDK
Product: DPDK
Version: 24.07
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: Normal
The Tx entry structures, both vector and scalar, are common across Intel
drivers, so provide a single definition to be used everywhere.
Signed-off-by: Bruce Richardson
---
drivers/net/_common_intel/tx.h| 27 +++
.../net/i40e/i40e_recycle_mbufs_vec_common.c | 2 +
The code for reassembling a single, multi-mbuf packet from multiple
buffers received from the NIC is duplicated across many drivers. Rather
than having multiple copies of this function, we can create an
"_common_intel" directory to hold such functions and consolidate
multiple functions down to a si
This RFC attempts to reduce the amount of code duplication across a
number of Intel NIC drivers, specifically: ixgbe, i40e, iavf, and ice.
The first patch extract a function from the Rx side, otherwise the
majority of the changes are on the Tx side, leading to a converged Tx
queue structure across
In preparation for merging the Tx structs for multiple drivers into a
single struct, rename the driver-specific pointers in each struct to
have a prefix on it, to avoid conflicts.
Signed-off-by: Bruce Richardson
---
drivers/net/i40e/i40e_fdir.c | 6 +--
.../net/i40e/i40e_recycl
Move the short function used to place mbufs on the SW Tx ring to common
code to avoid duplication.
Signed-off-by: Bruce Richardson
---
drivers/net/_common_intel/tx.h | 7 +++
drivers/net/i40e/i40e_rxtx_vec_altivec.c | 4 ++--
drivers/net/i40e/i40e_rxtx_vec_avx2.c| 4 ++--
dr
The queue structures of i40e and ice drivers are virtually identical, so
merge them into a common struct. This should allow easier function
merging in future using that common struct.
Signed-off-by: Bruce Richardson
---
drivers/net/_common_intel/tx.h| 55 +
driver
Across the various Intel drivers sometimes different names are given to
fields in the Tx queue structure which have the same function. Do some
renaming to align things better for future merging.
Signed-off-by: Bruce Richardson
---
drivers/net/i40e/i40e_rxtx.c| 6 +--
drivers/net/i40
Rather than having a two element array of context cache values inside
the Tx queue structure, convert it to a pointer to a cache at the end of
the structure. This makes future merging of the structure easier as we
don't need the "ixgbe_advctx_info" struct defined when defining a
combined queue stru
AVX-512 code paths for ice and i40e drivers are common, and differ from
the regular post-Tx free function in that the SW ring from which the
buffers are freed does not contain anything other than the mbuf pointer.
Merge these into a common function in intel_common to reduce
duplication.
Signed-off
The actions taken for post-Tx buffer free for the SSE and AVX drivers
for i40e, iavf and ice drivers are all common, so centralize those in
common/intel_eth driver.
Signed-off-by: Bruce Richardson
---
drivers/net/_common_intel/tx.h | 71
drivers/net/i40e/i40e_rx
Merge in additional fields used by the ixgbe driver and then convert it
over to using the common Tx queue structure.
Signed-off-by: Bruce Richardson
---
drivers/net/_common_intel/tx.h| 14 +++-
drivers/net/ixgbe/ixgbe_ethdev.c | 4 +-
.../ixgbe/ixgbe_recycle_mbufs_v
Switch the iavf driver to use the common Tx free function. This requires
one additional parameter to that function, since iavf sometimes uses
context descriptors which means that we have double the descriptors per
SW ring slot.
Signed-off-by: Bruce Richardson
---
drivers/net/_common_intel/tx.h
The functions to loop over the Tx queue and clean up all the mbufs on
it, e.g. for queue shutdown, is not device specific and so can move into
the common_intel headers. Only complication is ensuring that the
correct ring format, either minimal vector or full structure, is used.
Ice driver currently
Move some fields about to better pack the Tx queue structure and make
sure all data used by the vector codepaths is on the first cacheline of
the structure. Checking with "pahole" on 64-bit build, only one 6-byte
hole is left in the structure - on second cacheline - after this patch.
As part of th
Update driver to use the common cleanup function.
Signed-off-by: Bruce Richardson
---
drivers/net/ixgbe/ixgbe_rxtx.c| 22 +++---
drivers/net/ixgbe/ixgbe_rxtx.h| 1 -
drivers/net/ixgbe/ixgbe_rxtx_vec_common.h | 28 ++-
drivers/net/ixgbe/ixg
Update driver to be similar to the "ice" driver and use the common mbuf
ring cleanup code on shutdown of a Tx queue.
Signed-off-by: Bruce Richardson
---
drivers/net/i40e/i40e_ethdev.h | 4 +-
drivers/net/i40e/i40e_rxtx.c | 70 --
drivers/net/i40e/i40e_rxtx.h
Remove the custom vector Tx backlog entry function and use the standard
intel_common one, now that all vector drivers are using the same,
smaller ring structure.
Signed-off-by: Bruce Richardson
---
drivers/net/ixgbe/ixgbe_rxtx_vec_common.h | 10 --
drivers/net/ixgbe/ixgbe_rxtx_vec_neon.c
https://python-poetry.org/docs/basic-usage/#committing-your-poetrylock-file-to-version-control
I agree at first glance it appears like poetry.lock should go in the
.gitignore. However, the official docs state that in the case of developing
an application (like DTS), one should commit the generated
On Tue, Dec 10, 2024 at 07:14:56PM -0800, Stephen Hemminger wrote:
> On Tue, 10 Dec 2024 18:05:30 -0800
> Andre Muezerie wrote:
>
> > 1) Use portable variadic macros
> >
> > Many places are using a GCC extension related to variadic macros,
> > where a name prepends the ellipsis. This results in
Many places are using a GCC extension related to variadic macros,
where a name prepends the ellipsis. This results in a warning like
the one below when compiling the code with MSVC:
app\test-pmd\testpmd.h(1314): error C2608:
invalid token '...' in macro parameter list
Variadic macros became a
Many places are using a GCC extension related to variadic macros,
where a name prepends the ellipsis. This results in a warning like
the one below when compiling the code with MSVC:
app\test-pmd\testpmd.h(1314): error C2608:
invalid token '...' in macro parameter list
Variadic macros became a
Many places are using a GCC extension related to variadic macros,
where a name prepends the ellipsis. This results in a warning like
the one below when compiling the code with MSVC:
app\test-pmd\testpmd.h(1314): error C2608:
invalid token '...' in macro parameter list
Variadic macros became a
Many places are using a GCC extension related to variadic macros,
where a name prepends the ellipsis. This results in a warning like
the one below when compiling the code with MSVC:
app\test-pmd\testpmd.h(1314): error C2608:
invalid token '...' in macro parameter list
Variadic macros became a
Many places are using a GCC extension related to variadic macros,
where a name prepends the ellipsis. This results in a warning like
the one below when compiling the code with MSVC:
app\test-pmd\testpmd.h(1314): error C2608:
invalid token '...' in macro parameter list
Variadic macros became a
Many places are using a GCC extension related to variadic macros,
where a name prepends the ellipsis. This results in a warning like
the one below when compiling the code with MSVC:
app\test-pmd\testpmd.h(1314): error C2608:
invalid token '...' in macro parameter list
Variadic macros became a
Many places are using a GCC extension related to variadic macros,
where a name prepends the ellipsis. This results in a warning like
the one below when compiling the code with MSVC:
app\test-pmd\testpmd.h(1314): error C2608:
invalid token '...' in macro parameter list
Variadic macros became a
Many places are using a GCC extension related to variadic macros,
where a name prepends the ellipsis. This results in a warning like
the one below when compiling the code with MSVC:
app\test-pmd\testpmd.h(1314): error C2608:
invalid token '...' in macro parameter list
Variadic macros became a
Many places are using a GCC extension related to variadic macros,
where a name prepends the ellipsis. This results in a warning like
the one below when compiling the code with MSVC:
app\test-pmd\testpmd.h(1314): error C2608:
invalid token '...' in macro parameter list
Variadic macros became a
Many places are using a GCC extension related to variadic macros,
where a name prepends the ellipsis. This results in a warning like
the one below when compiling the code with MSVC:
app\test-pmd\testpmd.h(1314): error C2608:
invalid token '...' in macro parameter list
Variadic macros became a
Many places are using a GCC extension related to variadic macros,
where a name prepends the ellipsis. This results in a warning like
the one below when compiling the code with MSVC:
app\test-pmd\testpmd.h(1314): error C2608:
invalid token '...' in macro parameter list
Variadic macros became a
Many places are using a GCC extension related to variadic macros,
where a name prepends the ellipsis. This results in a warning like
the one below when compiling the code with MSVC:
app\test-pmd\testpmd.h(1314): error C2608:
invalid token '...' in macro parameter list
Variadic macros became a
Many places are using a GCC extension related to variadic macros,
where a name prepends the ellipsis. This results in a warning like
the one below when compiling the code with MSVC:
app\test-pmd\testpmd.h(1314): error C2608:
invalid token '...' in macro parameter list
Variadic macros became a
Many places are using a GCC extension related to variadic macros,
where a name prepends the ellipsis. This results in a warning like
the one below when compiling the code with MSVC:
app\test-pmd\testpmd.h(1314): error C2608:
invalid token '...' in macro parameter list
Variadic macros became a
Merge in the few additional fields used by iavf driver and convert it to
using the common Tx queue structure also.
Signed-off-by: Bruce Richardson
---
drivers/net/_common_intel/tx.h | 15 +++-
drivers/net/iavf/iavf.h | 2 +-
drivers/net/iavf/iavf_ethdev.c |
Adjust iavf driver to also use the common mbuf freeing functions on Tx
queue release/cleanup. The implementation is complicated a little by the
need to integrate the additional "has_ctx" parameter for the iavf code,
but changes in other drivers are minimal - just a constant "false"
parameter.
Sign
> This is first draft of new simplified TAP device that uses
> the Linux kernel ioring API to provide a read/write ring
> with kernel.
>
> This is split from tap device because there are so many
> unnecessary things in existing tap, and supporting ioring is
> better without ifdefs etc. The defa
I tested below 18 scenarios on RHEL 9.4 and didn't find any new dpdk issues.
- VM with device assignment(PF) throughput testing(1G hugepage size):
PASS
- VM with device assignment(PF) throughput testing(2M hugepage size) :
PASS
- VM with device assignment(VF) throughput testing: PAS
The AVX-512 code path used a smaller SW ring structure only containing
the mbuf pointer, but no other fields. The other fields are only used in
the scalar code path, so update all vector driver code paths (AVX2, SSE)
to use the smaller, faster structure.
Signed-off-by: Bruce Richardson
---
drive
The AVX-512 code path used a smaller SW ring structure only containing
the mbuf pointer, but no other fields. The other fields are only used in
the scalar code path, so update all vector driver code paths (AVX2, SSE,
Neon, Altivec) to use the smaller, faster structure.
Signed-off-by: Bruce Richard
The AVX-512 code path used a smaller SW ring structure only containing
the mbuf pointer, but no other fields. The other fields are only used in
the scalar code path, so update all vector driver code paths to use the
smaller, faster structure.
Signed-off-by: Bruce Richardson
---
drivers/net/_comm
With all drivers using the common Tx structure updated so that their
vector paths all use the simplified Tx mbuf ring format, it's no longer
necessary to have a separate flag for the ring format and for use of a
vector driver.
Remove the former flag and base all decisions off the vector flag. With
Many places are using a GCC extension related to variadic macros,
where a name prepends the ellipsis. This results in a warning like
the one below when compiling the code with MSVC:
app\test-pmd\testpmd.h(1314): error C2608:
invalid token '...' in macro parameter list
Variadic macros became a
Hi Maxime,
We have run perf top on dpdk-20.05 vs dpdk-22.11 but nothing of difference
in the top-hitter api's. In our analysis virtio-PMD CPU performance's not a
bottleneck (infact its more performant now) but its the GCP hypervisor
which isn't able to cope up with 3 times the Tx traffic load.
On
On Tue, Dec 10, 2024 at 6:00 PM Stephen Hemminger
wrote:
>
> On Tue, 10 Dec 2024 10:10:39 +0100
> David Marchand wrote:
>
> > +no_license_list=\
> > +':^.git* :^.mailmap :^.ci/* :^README :^MAINTAINERS :^VERSION :^ABI_VERSION
> > :^*/Kbuild '\
> > +':^*/README* :^license/ :^config/ :^buildtools/
https://bugs.dpdk.org/show_bug.cgi?id=1593
Xu,Hailin (hailinx...@intel.com) changed:
What|Removed |Added
Resolution|--- |DUPLICATE
CC|
https://bugs.dpdk.org/show_bug.cgi?id=1594
Xu,Hailin (hailinx...@intel.com) changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|U
https://bugs.dpdk.org/show_bug.cgi?id=1596
Bug ID: 1596
Summary: devbind no longer works unless VFIO_UNSAFE is enabled
Product: DPDK
Version: 24.11
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: major
>> struct zxdh_hw_internal zxdh_hw_internal[RTE_MAX_ETHPORTS];
>If you want to support primary/secondary in future,
>variables in BSS are not shared between primary and secondary process
This structure mainly registers some PCI ops and
will not be shared between primary/secondary proces
On Fri, Dec 6, 2024 at 12:29 PM Mattias Rönnblom wrote:
> I would wrap all RTE_LCORE_VAR_LCORE() and RTE_LCORE_VAR().
>
> static struct pmd_core_cfg *
> get_cfg_lcore(unsigned int lcore_id)
> {
> assure_lcore_cfgs_alloced();
> return RTE_LCORE_VAR_LCORE(lcore_cfgs, lcore_id);
> }
>
>> (np)network Processor initialize resources in host,
>> and initialize a channel for some tables insert/get/del.
>>
>> Signed-off-by: Junlong Wang
> This mostly looks good, just some small stuff.
Hi, Stephen
May I ask a question.
There are modification suggestions for the first patch
69 matches
Mail list logo
