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
>> 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
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
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
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
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
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
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
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
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
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 to use the
smaller, faster structure.
Signed-off-by: Bruce Richardson
---
drivers/net/_comm
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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 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
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 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
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
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/
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
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.
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
>
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 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 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
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
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* :^
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
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
> > > :^
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
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
> 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
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
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
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
69 matches
Mail list logo