On Tue, Feb 13, 2024 at 8:12 PM Tyler Retzlaff
wrote:
>
> The design of the macros requires a type to be provided to the macro.
>
> By expanding the type parameter inside of typeof it also inadvertently
> allows an expression to be used which appears not to have been intended
> after evaluating th
> From: Tyler Retzlaff [mailto:roret...@linux.microsoft.com]
> Sent: Wednesday, 14 February 2024 08.06
>
> * 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
> alignm
> -Original Message-
> From: Michael Baum
> Sent: Wednesday, February 7, 2024 16:55
> To: dev@dpdk.org
> Cc: Matan Azrad ; Dariusz Sosnowski
> ; Raslan Darawsheh ; Slava
> Ovsiienko ; Ori Kam ; Suanming
> Mou
> Subject: [PATCH v2 0/7] net/mlx5: support copy from inner fields
>
> This pat
On Mon, Feb 12, 2024 at 5:44 PM Jeremy Spewock wrote:
>
> On Tue, Feb 6, 2024 at 9:57 AM Juraj Linkeš
> wrote:
> >
> > We're currently filtering which test cases to run after some setup
> > steps, such as DPDK build, have already been taken. This prohibits us to
> > mark the test suites and case
On 2/14/24 08:05, Tyler Retzlaff wrote:
* 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
> 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 MSVC. It is proposed that
> we announce the fields to be __rte_deprecated (
> From: Tyler Retzlaff [mailto:roret...@linux.microsoft.com]
> Sent: Wednesday, 14 February 2024 00.33
>
> Here is the latest iteration of the proposed change to allow struct
> rte_mbuf
> to be consumed by MSVC.
>
> * Introduce an internal __rte_marker macro conditionally expanded for
> MSVC
>
On 2/14/2024 12:36 AM, Wathsala Vithanage wrote:
> The refcnt update of stored mbufs in memif driver is redundant since
> those mbufs are only freed in eth_memif_tx_zc(). No other place can
> free those stored mbufs quietly. By removing this redundant update
> single core dpdk memif performance can
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: separate logging functions ou
Reduce code duplication by providing a simple inline helper.
Signed-off-by: David Marchand
---
app/graph/utils.c | 13 ++--
app/test-eventdev/parser.c | 14 -
app/test-eventdev/parser.h | 8 -
app/test-mldev/parser.c
On Tue, Feb 13, 2024 at 7:35 PM Tyler Retzlaff
wrote:
>
> Replace use of __alignof__(T) and __alignof__(e) with C11 alignof(T)
> and alignof(typeof(e)) respectively to improve portability of the code
> between toolchains.
>
> v2:
> * expand series to replace use in entire source tree, now
>
On Tue, Feb 13, 2024 at 4:38 PM David Marchand
wrote:
>
> rte_common.h provides container_of if none is defined.
>
> The drivers headers touched by this commit either already include
> rte_common.h or use some other common macro defined in rte_common.h.
> As a consequence, it seems safe to assume
On Wed, Jan 31, 2024 at 1:19 AM Tyler Retzlaff
wrote:
>
> Remove use of statement expression syntax in expansion of
> MOVEUNALIGNED_LEFT47_IMM and MOVEUNALIGNED_LEFT47 macro expansions.
>
> There appears to be no need to use the statement expression compiler
> extension a simple block should work.
On Wed, Feb 14, 2024 at 01:12:19PM +0100, David Marchand wrote:
> Reduce code duplication by providing a simple inline helper.
>
> Signed-off-by: David Marchand
> ---
> app/graph/utils.c | 13 ++--
> app/test-eventdev/parser.c | 14 -
> app/te
On Wed, Feb 14, 2024 at 8:07 AM Tyler Retzlaff
wrote:
>
> Remove explicit alignment with __rte_aligned(sizeof(T)) on buf_iova
> field in the absence of packing the field should be correctly aligned.
>
> Signed-off-by: Tyler Retzlaff
> ---
> lib/mbuf/rte_mbuf_core.h | 6 +++---
> 1 file changed,
On Wed, Feb 14, 2024 at 02:12:17PM +0100, David Marchand wrote:
> On Wed, Feb 14, 2024 at 8:07 AM Tyler Retzlaff
> wrote:
> >
> > Remove explicit alignment with __rte_aligned(sizeof(T)) on buf_iova
> > field in the absence of packing the field should be correctly aligned.
> >
> > Signed-off-by: Ty
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
14/02/2024 15:32, Gregory Etelson:
> +The resizable template table API enables applications to dynamically adjust
> +capacity of template tables without disrupting the existing flow rules
> +operation. The resizable template table API allows applications to optimize
> the
> +memory usage and perfo
On Tue, 6 Feb 2024 at 21:28, Jerin Jacob wrote:
>
> On Tue, Feb 6, 2024 at 9:20 PM Prashant Upadhyaya
> wrote:
> >
> > On Tue, 6 Feb 2024 at 19:43, Bruce Richardson
> > wrote:
> > >
> > > On Tue, Feb 06, 2024 at 07:36:16PM +0530, Prashant Upadhyaya wrote:
> > > > Hi,
> > > >
> > > > I have a use
On 2/14/2024 2:32 PM, Gregory Etelson wrote:
> 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
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
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 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,
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;
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
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
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:
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
* 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
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
* 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
* 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
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
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/
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
>
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
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 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,
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
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
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
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
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 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
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
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
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
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
February 14, 2024
#
Attendees
* Patrick Robb
* Juraj Linkeš
* Thomas Monjalon
* Gregory Etelson
* Juraj Linkes
* Luca Vizzarro
* Nicholas Pratte
#
Agenda
* Addit
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
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
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/
>>
>>
> +#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 */
> +
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
> >
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
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
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
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
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
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
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
---
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/ice/ice_rxtx_vec_avx2.c | 30 +++---
drivers/net/ice/ice_rxtx_vec_avx512.c | 30
1 - 100 of 120 matches
Mail list logo
