Use rte_atomic_thread_fence instead of directly using
__atomic_thread_fence builtin gcc intrinsic
Signed-off-by: Tyler Retzlaff
Acked-by: Morten Brørup
---
lib/lpm/rte_lpm.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/lib/lpm/rte_lpm.c b/lib/lpm/rte_lpm.c
index 36305
Use rte_atomic_thread_fence instead of directly using
__atomic_thread_fence builtin gcc intrinsic
Signed-off-by: Tyler Retzlaff
Acked-by: Morten Brørup
---
lib/stack/rte_stack_lf_c11.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lib/stack/rte_stack_lf_c11.h b/lib/stack/r
Use rte_atomic_thread_fence instead of directly using
__atomic_thread_fence builtin gcc intrinsic
Signed-off-by: Tyler Retzlaff
Acked-by: Morten Brørup
---
lib/ring/rte_ring_c11_pvt.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/lib/ring/rte_ring_c11_pvt.h b/lib/ring/
Use rte_atomic_thread_fence instead of directly using
__atomic_thread_fence builtin gcc intrinsic
Signed-off-by: Tyler Retzlaff
Acked-by: Morten Brørup
---
lib/hash/rte_cuckoo_hash.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/lib/hash/rte_cuckoo_hash.c b/lib/
Use rte_atomic_thread_fence instead of directly using
__atomic_thread_fence builtin gcc intrinsic
Update rte_mcslock.h to use rte_atomic_thread_fence instead of
directly using internal __rte_atomic_thread_fence
Signed-off-by: Tyler Retzlaff
Acked-by: Morten Brørup
---
lib/eal/common/eal_common
Use rte_atomic_thread_fence instead of directly using
__atomic_thread_fence builtin gcc intrinsic
Signed-off-by: Tyler Retzlaff
Acked-by: Morten Brørup
---
lib/distributor/rte_distributor.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lib/distributor/rte_distributor.c
b/
Replace use of __atomic_thread_fence with rte_atomic_thread_fence.
Notes:
The rest of lib/lpm will be converted to rte_atomic in a separate
series (to be submitted soon).
There are existing checkpatches checks that catch use of both
__atomic_thread_fence and __rte_atomic_thread_fence in
Update to reference newly named anonymous union markers supported by
standard C and stop referencing zero sized compiler extension markers.
Signed-off-by: Tyler Retzlaff
---
drivers/net/cnxk/cn10k_rx.h| 50 +-
drivers/net/cnxk/cn9k_rx.h | 34 ++
Update to reference newly named anonymous union markers supported by
standard C and stop referencing zero sized compiler extension markers.
Signed-off-by: Tyler Retzlaff
---
drivers/net/hns3/hns3_rxtx_vec.c | 22 +++---
drivers/net/hns3/hns3_rxtx_vec_neon.h | 28
Update to reference newly named anonymous union markers supported by
standard C and stop referencing zero sized compiler extension markers.
Signed-off-by: Tyler Retzlaff
---
examples/dma/dmafwd.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/examples/dma/dmafwd.c b/exam
Update to reference newly named anonymous union markers supported by
standard C and stop referencing zero sized compiler extension markers.
Signed-off-by: Tyler Retzlaff
---
drivers/common/idpf/idpf_common_rxtx.c| 4 +-
drivers/common/idpf/idpf_common_rxtx_avx512.c | 60 +---
Update to reference newly named anonymous union markers supported by
standard C and stop referencing zero sized compiler extension markers.
Signed-off-by: Tyler Retzlaff
---
drivers/net/ionic/ionic_lif.c | 8
drivers/net/ionic/ionic_rxtx_sg.c | 4 ++--
drivers/net/ionic/ioni
Update to reference newly named anonymous union markers supported by
standard C and stop referencing zero sized compiler extension markers.
Signed-off-by: Tyler Retzlaff
---
drivers/net/thunderx/nicvf_ethdev.c | 4 ++--
drivers/net/thunderx/nicvf_rxtx.h | 4 ++--
2 files changed, 4 insertions(
Update to reference newly named anonymous union markers supported by
standard C and stop referencing zero sized compiler extension markers.
Signed-off-by: Tyler Retzlaff
---
drivers/net/virtio/virtio_rxtx_packed.h | 4 ++--
drivers/net/virtio/virtio_rxtx_packed_avx.h | 14 +++---
Update to reference newly named anonymous union markers supported by
standard C and stop referencing zero sized compiler extension markers.
Signed-off-by: Tyler Retzlaff
---
drivers/net/bnxt/bnxt_rxtx_vec_avx2.c | 18 +-
drivers/net/bnxt/bnxt_rxtx_vec_common.h | 4 ++--
driver
Update to reference newly named anonymous union markers supported by
standard C and stop referencing zero sized compiler extension markers.
Signed-off-by: Tyler Retzlaff
---
drivers/net/fm10k/fm10k_rxtx_vec.c | 24
1 file changed, 12 insertions(+), 12 deletions(-)
diff
Update to reference newly named anonymous union markers supported by
standard C and stop referencing zero sized compiler extension markers.
Signed-off-by: Tyler Retzlaff
---
drivers/net/enic/enic.h | 2 +-
drivers/net/enic/enic_main.c | 4 ++--
drivers/net/enic/enic_rxtx
Update to reference newly named anonymous union markers supported by
standard C and stop referencing zero sized compiler extension markers.
Signed-off-by: Tyler Retzlaff
---
drivers/net/sfc/sfc_ef100_rx.c | 10 +-
drivers/net/sfc/sfc_ef10_rx.c | 14 +++---
2 files changed, 12 in
Update to reference newly named anonymous union markers supported by
standard C and stop referencing zero sized compiler extension markers.
Signed-off-by: Tyler Retzlaff
---
drivers/net/mlx5/mlx5_rxq.c | 6 ++--
drivers/net/mlx5/mlx5_rxtx_vec.h | 16 +--
drivers/net
Update to reference newly named anonymous union markers supported by
standard C and stop referencing zero sized compiler extension markers.
Signed-off-by: Tyler Retzlaff
---
drivers/net/ixgbe/ixgbe_rxtx_vec_common.h | 4 +--
drivers/net/ixgbe/ixgbe_rxtx_vec_neon.c | 12 -
drivers/net/
Update to reference newly named anonymous union markers supported by
standard C and stop referencing zero sized compiler extension markers.
Signed-off-by: Tyler Retzlaff
---
drivers/net/ice/ice_rxtx_vec_avx2.c | 30 +++---
drivers/net/ice/ice_rxtx_vec_avx512.c | 30
Update to reference newly named anonymous union markers supported by
standard C and stop referencing zero sized compiler extension markers.
Signed-off-by: Tyler Retzlaff
---
drivers/net/iavf/iavf_rxtx_vec_avx2.c | 60 ++---
drivers/net/iavf/iavf_rxtx_vec_avx512.c | 60 +
Update to reference newly named anonymous union markers supported by
standard C and stop referencing zero sized compiler extension markers.
Signed-off-by: Tyler Retzlaff
---
drivers/net/i40e/i40e_rxtx_vec_altivec.c | 14 ++---
drivers/net/i40e/i40e_rxtx_vec_avx2.c| 30 ++-
Update to reference newly named anonymous union markers supported by
standard C and stop referencing zero sized compiler extension markers.
Signed-off-by: Tyler Retzlaff
---
lib/mbuf/rte_mbuf.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/lib/mbuf/rte_mbuf.h b/lib/mbuf
Provide a macro that allows conditional expansion of RTE_MARKER fields
to empty to allow rte_mbuf to be used with MSVC. It is proposed that
we announce the fields to be __rte_deprecated (currently disabled).
Introduce C11 anonymous unions to permit aliasing of well-known
offsets by name into the r
The zero sized RTE_MARKER typedefs are a GCC extension unsupported by
MSVC. This series adds new fields and allows deprecation of the old.
Introduce new anonymous union fields with mbuf_ prefix for cacheline0,
rearm_data, rx_descriptor_fields1, and cacheline1.
Remove in-tree use of the zero sized
Template table creation API sets table flows capacity.
If application needs more flows then the table was designed for,
the following procedures must be completed:
1. Create a new template table with larger flows capacity.
2. Re-create existing flows in the new table and delete flows from
the or
Hello Ferruh,
<...>
Syntax above is odd, why not move parenthesis to first line.
Agree that's odd style.
DPDK prefers that way.
Please check rte_flow_driver.h::rte_flow.ops.
True that is also odd but at least it is function pointers in a struct,
but this is regular function deceleration, w
https://bugs.dpdk.org/show_bug.cgi?id=1379
Bug ID: 1379
Summary: qede pmd driver does not work in Debian Bookworm
Product: DPDK
Version: 22.11
Hardware: x86
OS: Linux
Status: UNCONFIRMED
Severity: normal
I keep meaning to mention this because we've been patching the ixgbe driver for
a while...
In ixgbe_ethdev.c, function ixgbe_dev_link_update_share(), we find the
following:
/* BSD has no interrupt mechanism, so force NIC status synchronization. */
#ifdef RTE_EXEC_ENV_FREEBSD
wait = 1
08/11/2023 19:49, Tyler Retzlaff:
> On Wed, Nov 08, 2023 at 06:04:47PM +0100, Thomas Monjalon wrote:
> > 02/11/2023 04:04, Tyler Retzlaff:
> > > Replace use of __atomic_thread_fence with __rte_atomic_thread_fence.
> > >
> > > It may be appropriate to use rte_atomic_thread_fence instead but it
> >
> +#define HN_VLAN_CFI_SHIFT12
> +#define HN_VLAN_PRI_SHIFT13
> +#define HN_VLAN_PRI_MASK 0xe000 /* Priority Code Point */
> +#define HN_VLAN_CFI_MASK 0x1000 /* Canonical Format Indicator / Drop
> Eligible Indicator */
> +#define HN_VLAN_VID_MASK 0x0fff /* VLAN Identifier */
> +
On 2/14/2024 5:07 PM, Etelson, Gregory wrote:
> Hello Ferruh,
>
>>
>> Having conflict while applying the patch, can you please rebase it on
>> latest 'next-net'?
>
> Will rebase and update the patch.
>
>>
>>> + Query wheather template table can be resized.
>>>
>>
>> s/wheather/whether/
>>
>>
Hello all,
As discussed in the previous CI testing meeting, it will be advantageous
for us to shift the (every other week) DPDK CI meetings forward or
backwards 1 week to get it onto a different cadence.
That will allow us to have the DTS meetings 1 week, and the CI meetings on
the off week, inst
Removed the requirement that the number of pipeline input ports be a
power of 2, which is problematic for many real life use-cases. Also
adding checks for the output port validity used for sending the
current packet.
Signed-off-by: Cristian Dumitrescu
---
lib/pipeline/rte_swx_pipeline.c
Removed the requirement that the number of pipeline input ports be a
power of 2, which is problematic for many real life use-cases. Also
adding checks for the output port validity used for sending the
current packet.
Signed-off-by: Cristian Dumitrescu
---
lib/pipeline/rte_swx_pipeline.c
February 14, 2024
#
Attendees
* Patrick Robb
* Juraj Linkeš
* Thomas Monjalon
* Gregory Etelson
* Juraj Linkes
* Luca Vizzarro
* Nicholas Pratte
#
Agenda
* Addit
On Wed, Feb 14, 2024 at 3:00 PM Dumitrescu, Cristian <
cristian.dumitre...@intel.com> wrote:
>
>
> [Cristian]
> Yes, you are right, we do have a DTS test suite for the pipeline library.
>
> It would be great to run it automatically as part of the CI testing. Just
> a word of caution though: I am n
On Wed, Feb 14, 2024 at 11:46:01AM +0100, Morten Brørup wrote:
> > From: Tyler Retzlaff [mailto:roret...@linux.microsoft.com]
> > Sent: Wednesday, 14 February 2024 00.33
> >
> > Provide a macro that allows conditional expansion of RTE_MARKER fields
> > to empty to allow rte_mbuf to be used with MS
Versions of Mellanox NICs starting from CX5 have device counters
related to PCI. These counters are helpful in debugging IO
bottlenecks. For instance, the outbound_pci_stalled_rd and
outbound_pci_stalled_wr counters can help with identifying NIC
stalls due to insufficient PCI credits, which otherwi
Hi Patrick,
See my comment below under your reply.
From: Patrick Robb
Sent: Wednesday, February 14, 2024 7:32 PM
To: Aaron Conole
Cc: Ferruh Yigit ; Dumitrescu, Cristian
; dev@dpdk.org; sta...@dpdk.org; Marchand, David
; Richardson, Bruce
Subject: Re: [PATCH V2] examples/pipeline: fix inclu
Hi Aaron/Cristian,
On Wed, Feb 14, 2024 at 11:25 AM Aaron Conole wrote:
> Ferruh Yigit writes:
>
> > On 2/13/2024 5:38 PM, Cristian Dumitrescu wrote:
> >> When rte_log.h was moved to a new directory, the include path was not
> >> updated for the generated C code produced by the pipeline library
Hello Patrick,
Did you have time to check the Unit Test design ?
Do you think it can be used for short functional DTS tests ?
Regards,
Gregory
From: Gregory Etelson
Sent: Wednesday, January 31, 2024 09:43
To: Patrick Robb
Cc: Gregory Etelson ; Jeremy Spewock
;
Hi Ferruh,
> -Original Message-
> From: Ferruh Yigit
> Sent: Wednesday, February 14, 2024 11:22 AM
> To: Dumitrescu, Cristian ; dev@dpdk.org
> Cc: sta...@dpdk.org; Marchand, David ; Aaron
> Conole ; Richardson, Bruce
>
> Subject: Re: [PATCH V2] examples/pipeline: fix include path for rte
Hi Wenjing,
Please find comments inlined
On 05/01/2024 08:16, wenjing.q...@intel.com wrote:
From: Wenjing Qiao
Add TDI implementation to a flow engine.
Signed-off-by: Wenjing Qiao
---
--- /dev/null
+++ b/drivers/net/cpfl/cpfl_tdi.c
@@ -0,0 +1,1282 @@
+/* SPDX-License-Identifier: BSD-3-Clau
Hello Ferruh,
Having conflict while applying the patch, can you please rebase it on
latest 'next-net'?
Will rebase and update the patch.
+Query wheather template table can be resized.
s/wheather/whether/
<...>
fix in updated patch
+__rte_experimental
+bool
+rte_flow_template
Enable the AF_XDP PMD to retrieve the xskmap
from a pinned eBPF map. This map is expected
to be pinned by an external entity like the
AF_XDP Device Plugin. This enabled unprivileged
pods to create and use AF_XDP sockets.
Signed-off-by: Maryam Tahhan
---
doc/guides/howto/af_xdp_dp.rst | 3
The original 'use_cni' implementation, was added
to enable support for the AF_XDP PMD in a K8s env
without any escalated privileges.
However 'use_cni' used a hardcoded socket rather
than a configurable one. If a DPDK pod is requesting
multiple net devices and these devices are from
different pools,
Fixup the references to the AF_XDP Device Plugin in
the documentation (was referred to as CNI previously)
and document the single netdev limitation for deploying
an AF_XDP based DPDK pod. Also renames af_xdp_cni.rst to
af_xdp_dp.rst
Fixes: 7fc6ae50369d ("net/af_xdp: support CNI Integration")
Cc: s
The original `use_cni` implementation was limited to
supporting only a single netdev in a DPDK pod. This patchset
aims to fix this limitation transparently to the end user.
It will also enable compatibility with the latest AF_XDP
Device Plugin.
Signed-off-by: Maryam Tahhan
---
v9:
* Fixup checkp
24/01/2024 14:33, Thomas Monjalon:
> 18/12/2023 10:18, Bruce Richardson:
> > On Fri, Dec 15, 2023 at 01:53:21PM -0800, Stephen Hemminger wrote:
> > > On Fri, 15 Dec 2023 17:26:24 +
> > > Euan Bourke wrote:
> > >
> > > > A recent thread on the mailing list[1] discussed corelist and coremask
>
26/01/2024 07:10, Chengwen Feng:
> Introduce argparse library (which was inspired by the thread [1]),
> compared with getopt, it makes it easy to write user-friendly
> command-like program.
>
> Note: the 2nd commit contains usage examples.
>
> [1]
> https://patchwork.dpdk.org/project/dpdk/patch/
On Wed, Feb 14, 2024 at 2:49 AM Juraj Linkeš wrote:
>
> Hi Jeremy,
>
> Just a reminder, please strip the parts you're not commenting on.
>
> > > +def __init__(self, *args, **kwargs):
> > > +"""Extend the constructor with extra file handlers."""
> > > +self._extra_file_handlers
* Move __rte_aligned from the end of {struct,union} definitions to
be between {struct,union} and tag.
The placement between {struct,union} and the tag allows the desired
alignment to be imparted on the type regardless of the toolchain being
used for all of GCC, LLVM, MSVC compilers buildin
* Move __rte_aligned from the end of {struct,union} definitions to
be between {struct,union} and tag.
The placement between {struct,union} and the tag allows the desired
alignment to be imparted on the type regardless of the toolchain being
used for all of GCC, LLVM, MSVC compilers buildin
* Move __rte_aligned from the end of {struct,union} definitions to
be between {struct,union} and tag.
The placement between {struct,union} and the tag allows the desired
alignment to be imparted on the type regardless of the toolchain being
used for all of GCC, LLVM, MSVC compilers buildin
* Move __rte_aligned from the end of {struct,union} definitions to
be between {struct,union} and tag.
The placement between {struct,union} and the tag allows the desired
alignment to be imparted on the type regardless of the toolchain being
used for all of GCC, LLVM, MSVC compilers buildin
* Move __rte_aligned from the end of {struct,union} definitions to
be between {struct,union} and tag.
The placement between {struct,union} and the tag allows the desired
alignment to be imparted on the type regardless of the toolchain being
used for all of GCC, LLVM, MSVC compilers buildin
* Move __rte_aligned from the end of {struct,union} definitions to
be between {struct,union} and tag.
The placement between {struct,union} and the tag allows the desired
alignment to be imparted on the type regardless of the toolchain being
used for all of GCC, LLVM, MSVC compilers buildin
* Move __rte_aligned from the end of {struct,union} definitions to
be between {struct,union} and tag.
The placement between {struct,union} and the tag allows the desired
alignment to be imparted on the type regardless of the toolchain being
used for all of GCC, LLVM, MSVC compilers buildin
* Move __rte_aligned from the end of {struct,union} definitions to
be between {struct,union} and tag.
The placement between {struct,union} and the tag allows the desired
alignment to be imparted on the type regardless of the toolchain being
used for all of GCC, LLVM, MSVC compilers buildin
* Move __rte_aligned from the end of {struct,union} definitions to
be between {struct,union} and tag.
The placement between {struct,union} and the tag allows the desired
alignment to be imparted on the type regardless of the toolchain being
used for all of GCC, LLVM, MSVC compilers buildin
* Move __rte_aligned from the end of {struct,union} definitions to
be between {struct,union} and tag.
The placement between {struct,union} and the tag allows the desired
alignment to be imparted on the type regardless of the toolchain being
used for all of GCC, LLVM, MSVC compilers buildin
* Move __rte_aligned from the end of {struct,union} definitions to
be between {struct,union} and tag.
The placement between {struct,union} and the tag allows the desired
alignment to be imparted on the type regardless of the toolchain being
used for all of GCC, LLVM, MSVC compilers buildin
* Move __rte_aligned from the end of {struct,union} definitions to
be between {struct,union} and tag.
The placement between {struct,union} and the tag allows the desired
alignment to be imparted on the type regardless of the toolchain being
used for all of GCC, LLVM, MSVC compilers buildin
* Move __rte_aligned from the end of {struct,union} definitions to
be between {struct,union} and tag.
The placement between {struct,union} and the tag allows the desired
alignment to be imparted on the type regardless of the toolchain being
used for all of GCC, LLVM, MSVC compilers buildin
* Move __rte_aligned from the end of {struct,union} definitions to
be between {struct,union} and tag.
The placement between {struct,union} and the tag allows the desired
alignment to be imparted on the type regardless of the toolchain being
used for all of GCC, LLVM, MSVC compilers buildin
* Move __rte_aligned from the end of {struct,union} definitions to
be between {struct,union} and tag.
The placement between {struct,union} and the tag allows the desired
alignment to be imparted on the type regardless of the toolchain being
used for all of GCC, LLVM, MSVC compilers buildin
* Move __rte_aligned from the end of {struct,union} definitions to
be between {struct,union} and tag.
The placement between {struct,union} and the tag allows the desired
alignment to be imparted on the type regardless of the toolchain being
used for all of GCC, LLVM, MSVC compilers buildin
* Move __rte_aligned from the end of {struct,union} definitions to
be between {struct,union} and tag.
The placement between {struct,union} and the tag allows the desired
alignment to be imparted on the type regardless of the toolchain being
used for all of GCC, LLVM, MSVC compilers buildin
* Move __rte_aligned from the end of {struct,union} definitions to
be between {struct,union} and tag.
The placement between {struct,union} and the tag allows the desired
alignment to be imparted on the type regardless of the toolchain being
used for all of GCC, LLVM, MSVC compilers buildin
* Move __rte_aligned from the end of {struct,union} definitions to
be between {struct,union} and tag.
The placement between {struct,union} and the tag allows the desired
alignment to be imparted on the type regardless of the toolchain being
used for all of GCC, LLVM, MSVC compilers buildin
* Move __rte_aligned from the end of {struct,union} definitions to
be between {struct,union} and tag.
The placement between {struct,union} and the tag allows the desired
alignment to be imparted on the type regardless of the toolchain being
used for all of GCC, LLVM, MSVC compilers buildin
* Move __rte_aligned from the end of {struct,union} definitions to
be between {struct,union} and tag.
The placement between {struct,union} and the tag allows the desired
alignment to be imparted on the type regardless of the toolchain being
used for all of GCC, LLVM, MSVC compilers buildin
* Move __rte_aligned from the end of {struct,union} definitions to
be between {struct,union} and tag.
The placement between {struct,union} and the tag allows the desired
alignment to be imparted on the type regardless of the toolchain being
used for all of GCC, LLVM, MSVC compilers buildin
* Move __rte_aligned from the end of {struct,union} definitions to
be between {struct,union} and tag.
The placement between {struct,union} and the tag allows the desired
alignment to be imparted on the type regardless of the toolchain being
used for all of GCC, LLVM, MSVC compilers buildin
* Move __rte_aligned from the end of {struct,union} definitions to
be between {struct,union} and tag.
The placement between {struct,union} and the tag allows the desired
alignment to be imparted on the type regardless of the toolchain being
used for all of GCC, LLVM, MSVC compilers buildin
* Move __rte_aligned from the end of {struct,union} definitions to
be between {struct,union} and tag.
The placement between {struct,union} and the tag allows the desired
alignment to be imparted on the type regardless of the toolchain being
used for all of GCC, LLVM, MSVC compilers buildin
* Move __rte_aligned from the end of {struct,union} definitions to
be between {struct,union} and tag.
The placement between {struct,union} and the tag allows the desired
alignment to be imparted on the type regardless of the toolchain being
used for all of GCC, LLVM, MSVC compilers buildin
* Move __rte_aligned from the end of {struct,union} definitions to
be between {struct,union} and tag.
The placement between {struct,union} and the tag allows the desired
alignment to be imparted on the type regardless of the toolchain being
used for all of GCC, LLVM, MSVC compilers buildin
* Move __rte_aligned from the end of {struct,union} definitions to
be between {struct,union} and tag.
The placement between {struct,union} and the tag allows the desired
alignment to be imparted on the type regardless of the toolchain being
used for all of GCC, LLVM, MSVC compilers buildin
* Move __rte_aligned from the end of {struct,union} definitions to
be between {struct,union} and tag.
The placement between {struct,union} and the tag allows the desired
alignment to be imparted on the type regardless of the toolchain being
used for all of GCC, LLVM, MSVC compilers buildin
* Move __rte_aligned from the end of {struct,union} definitions to
be between {struct,union} and tag.
The placement between {struct,union} and the tag allows the desired
alignment to be imparted on the type regardless of the toolchain being
used for all of GCC, LLVM, MSVC compilers buildin
* Move __rte_aligned from the end of {struct,union} definitions to
be between {struct,union} and tag.
The placement between {struct,union} and the tag allows the desired
alignment to be imparted on the type regardless of the toolchain being
used for all of GCC, LLVM, MSVC compilers buildin
* Move __rte_aligned from the end of {struct,union} definitions to
be between {struct,union} and tag.
The placement between {struct,union} and the tag allows the desired
alignment to be imparted on the type regardless of the toolchain being
used for all of GCC, LLVM, MSVC compilers buildin
* Move __rte_aligned from the end of {struct,union} definitions to
be between {struct,union} and tag.
The placement between {struct,union} and the tag allows the desired
alignment to be imparted on the type regardless of the toolchain being
used for all of GCC, LLVM, MSVC compilers buildin
* Move __rte_aligned from the end of {struct,union} definitions to
be between {struct,union} and tag.
The placement between {struct,union} and the tag allows the desired
alignment to be imparted on the type regardless of the toolchain being
used for all of GCC, LLVM, MSVC compilers buildin
* Move __rte_aligned from the end of {struct,union} definitions to
be between {struct,union} and tag.
The placement between {struct,union} and the tag allows the desired
alignment to be imparted on the type regardless of the toolchain being
used for all of GCC, LLVM, MSVC compilers buildin
Replace use of __rte_aligned_16 with C11 alignas(16) and garbage collect
the __rte_aligned_16 macro which was only used once.
Signed-off-by: Tyler Retzlaff
Acked-by: Morten Brørup
---
lib/sched/rte_sched.c| 21 +++--
lib/sched/rte_sched_common.h | 2 --
2 files changed,
* Move __rte_aligned from the end of {struct,union} definitions to
be between {struct,union} and tag.
The placement between {struct,union} and the tag allows the desired
alignment to be imparted on the type regardless of the toolchain being
used for all of GCC, LLVM, MSVC compilers buildin
MSVC __declspec(align(#)) is limited and accepts only integer literals
as opposed to constant expressions. define XMM_SIZE to be 16 instead of
sizeof(xmm_t) and static_assert that sizeof(xmm_t) == 16 for
compatibility.
Signed-off-by: Tyler Retzlaff
Acked-by: Morten Brørup
---
lib/eal/x86/includ
* Expand __rte_aligned(a) to __declspec(align(a)) when building
with MSVC.
* Move __rte_aligned from the end of {struct,union} definitions to
be between {struct,union} and tag.
The placement between {struct,union} and the tag allows the desired
alignment to be imparted on the type regardl
This series normalizes type and object alignment by doing the following.
Fill in expansion of existing __rte_aligned, __rte_cache_aligned and
__rte_cache_min_aligned macros for MSVC.
Where __rte_aligned, __rte_cache_aligned and __rte_cache_min_aligned
are used to align *types* move them to a loca
Ferruh Yigit writes:
> On 2/13/2024 5:38 PM, Cristian Dumitrescu wrote:
>> When rte_log.h was moved to a new directory, the include path was not
>> updated for the generated C code produced by the pipeline library,
>> which results in build failure for this code.
>>
>> Fixes: 09ce41310930 ("log:
Sorry folks
Just spotted the checkpatch warnings :( I will fix these now.
BR
Maryam
On 14/02/2024 16:06, Maryam Tahhan wrote:
The original `use_cni` implementation was limited to
supporting only a single netdev in a DPDK pod. This patchset
aims to fix this limitation transparently to the end
Enable the AF_XDP PMD to retrieve the xskmap
from a pinned eBPF map. This map is expected
to be pinned by an external entity like the
AF_XDP Device Plugin. This enabled unprivileged
pods to create and use AF_XDP sockets.
Signed-off-by: Maryam Tahhan
---
doc/guides/howto/af_xdp_dp.rst | 3
Hi Yaron,
I can see some possible issues with your code, please see below.
From: Yaron Illouz
Sent: Saturday, February 3, 2024 7:03 PM
To: dev@dpdk.org; 'us...@dpdk.org'
Subject: rss calculation as the nic
[Snip]
static inline uint32_t
do_softrss(struct rte_mbuf *m)
{
uint32_t input_len;
The original 'use_cni' implementation, was added
to enable support for the AF_XDP PMD in a K8s env
without any escalated privileges.
However 'use_cni' used a hardcoded socket rather
than a configurable one. If a DPDK pod is requesting
multiple net devices and these devices are from
different pools,
Fixup the references to the AF_XDP Device Plugin in
the documentation (was referred to as CNI previously)
and document the single netdev limitation for deploying
an AF_XDP based DPDK pod. Also renames af_xdp_cni.rst to
af_xdp_dp.rst
Fixes: 7fc6ae50369d ("net/af_xdp: support CNI Integration")
Cc: s
The original `use_cni` implementation was limited to
supporting only a single netdev in a DPDK pod. This patchset
aims to fix this limitation transparently to the end user.
It will also enable compatibility with the latest AF_XDP
Device Plugin.
Signed-off-by: Maryam Tahhan
---
v8:
* Go back to u
1 - 100 of 120 matches
Mail list logo
