> From: Tyler Retzlaff [mailto:roret...@linux.microsoft.com]
> Sent: Friday, 23 February 2024 00.46
>
> RTE_LOG_LINE cannot be augmented with a prefix format and arguments
> without the user of RTE_LOG_LINE using the args... and ## args compiler
> extension to conditionally remove trailing comma w
Dear maintainers,
Is it easier for you to spot if we ack a series in patch 0, patch 1, or the
last patch of the series? Or don't you have any preferences?
Med venlig hilsen / Kind regards,
-Morten Brørup
Add hyphen to the regex, which is needed for drivers such as vfio-pci.
Fixes: 88489c0501af ("dts: add smoke tests")
Cc: jspew...@iol.unh.edu
Signed-off-by: Juraj Linkeš
---
dts/tests/TestSuite_smoke_tests.py | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/dts/tests/TestSuite_
On 2/22/24 21:28, Konstantin Ananyev wrote:
+CC: Ethernet API maintainers
+CC: Jerin (commented on another branch of this thread)
From: Konstantin Ananyev [mailto:konstantin.anan...@huawei.com]
Sent: Sunday, 11 February 2024 16.04
TSO breaks when MSS spans more than 8 data fragments. Those
On 2/23/2024 8:15 AM, Morten Brørup wrote:
> Dear maintainers,
>
> Is it easier for you to spot if we ack a series in patch 0, patch 1, or the
> last patch of the series? Or don't you have any preferences?
>
When a patch is ack'ed, not cover letter (patch 0), patchwork detects it
and both shows
On Thu, Feb 22, 2024 at 3:38 PM Rahul Bhansali wrote:
>
> LLC transaction optimization by using LDWB LDTYPE option
> in SG preparation for Tx. With this, if data is present
> and dirty in LLC then the LLC would mark the data clean.
>
> Signed-off-by: Rahul Bhansali
Series applied to dpdk-next-ne
On 2/23/2024 2:42 AM, Chaoyong He wrote:
> From: Long Wu
>
> Add a function to check if a device is representor port, also
> modified the related codes for PMDs.
>
Thanks Long for the patch.
> Signed-off-by: Long Wu
> Reviewed-by: Chaoyong He
> Reviewed-by: Peng Zhang
> ---
> doc/guides/re
Hi Vipin,
On 2023/12/20 0:40, Vipin Varghese wrote:
> Modify the user display data with total average latency per worker.
>
> Signed-off-by: Vipin Varghese
> ---
> app/test-dma-perf/benchmark.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/app/test-dma-perf/benchma
On 2024-02-22 10:22, Morten Brørup wrote:
From: Mattias Rönnblom [mailto:mattias.ronnb...@ericsson.com]
Sent: Tuesday, 20 February 2024 09.49
Introduce DPDK per-lcore id variables, or lcore variables for short.
An lcore variable has one value for every current and future lcore
id-equipped threa
On 2024-02-22 10:42, Morten Brørup wrote:
From: Mattias Rönnblom [mailto:mattias.ronnb...@ericsson.com]
Sent: Tuesday, 20 February 2024 09.49
Replace static array of cache-aligned structs with an lcore variable,
to slightly benefit code simplicity and performance.
Signed-off-by: Mattias Rönnblo
There are use cases where a SA should be able to use different cryptodevs on
different lcores, for example there can be cryptodevs with just 1 qp per VF.
For this purpose this patch relaxes the check in create lookaside session
function.
Also add a check to verify that a CQP is available for the c
Other than the one point below,
Reviewed-by: Juraj Linkeš
> diff --git a/config/arm/meson.build b/config/arm/meson.build
> index 36f21d2259..d05d54b564 100644
> --- a/config/arm/meson.build
> +++ b/config/arm/meson.build
> @@ -695,13 +698,37 @@ if update_flags
>
> machine_args = [] # Clear
On 2/23/2024 1:45 AM, Yunjian Wang wrote:
> In xdp_umem_configure() allocated some resources for the
> xsk umem, we should delete them when xsk configure fails,
> otherwise it will lead to resources leak.
>
> Fixes: f1debd77efaf ("net/af_xdp: introduce AF_XDP PMD")
> Cc: sta...@dpdk.org
>
> Signe
On Thu, Feb 22, 2024 at 1:45 PM wrote:
>
> From: Pavan Nikhilesh
>
> Some ARM CPUs have specific march requirements and
> are not compatible with the supported march list.
> Add fallback march in case the mcpu and the march
> advertised in the part_number_config are not supported
> by the compile
On 2/23/2024 3:21 AM, Rongwei Liu wrote:
> Update the name to the right one: "src_tag_index"
>
> Fixes: c23626f27b09 ("ethdev: add MPLS header modification")
> Cc: sta...@dpdk.org
>
> Signed-off-by: Rongwei Liu
> Acked-by: Dariusz Sosnowski
>
Acked-by: Ferruh Yigit
On 2/23/2024 3:21 AM, Rongwei Liu wrote:
> v2: rebase.
>
> Rongwei Liu (2):
> app/testpmd: fix modify tag typo
> net/mlx5: fix modify flex item error
>
Series applied to dpdk-next-net/main, thanks.
SW PMDs increment IPsec Multi-buffer version to 1.4.
A minimum IPsec Multi-buffer version of 1.4 or greater is now required.
Signed-off-by: Sivaramakrishnan Venkat
Acked-by: Ciara Power
Acked-by: Pablo de Lara
---
v4:
- 24.03 release notes updated to bump minimum IPSec Multi-buffer
SW PMDs documentation is updated to remove details of unsupported IPsec
Multi-buffer versions.DPDK older than 20.11 is end of life. So, older
DPDK versions are removed from the Crypto library version table.
Signed-off-by: Sivaramakrishnan Venkat
Acked-by: Pablo de Lara
---
v3:
- added seco
SW PMDs increment IPsec Multi-buffer version to 1.4.
A minimum IPsec Multi-buffer version of 1.4 or greater is now required.
Signed-off-by: Sivaramakrishnan Venkat
Acked-by: Ciara Power
Acked-by: Pablo de Lara
---
v4:
- 24.03 release notes updated to bump minimum IPSec Multi-buffer
SW PMDs documentation is updated to remove details of unsupported IPsec
Multi-buffer versions.DPDK older than 20.11 is end of life. So, older
DPDK versions are removed from the Crypto library version table.
Signed-off-by: Sivaramakrishnan Venkat
Acked-by: Pablo de Lara
---
v3:
- added seco
On Wed, Feb 21, 2024 at 4:10 PM Bruce Richardson
wrote:
>
> This patchset makes rewording improvements to the eventdev doxygen
> documentation to try and ensure that it is as clear as possible,
> describes the implementation as accurately as possible, and is
> consistent within itself.
>
> Most ch
On Thu, Mar 9, 2023 at 9:53 PM Stephen Hemminger
wrote:
>
> On Thu, 9 Feb 2023 17:49:31 +0100
> Morten Brørup wrote:
>
> > > rte_memcpy(old, new, sizeof(struct nig_stats));
> > >
> > > -rte_memcpy(&(estats->rx_stat_ifhcinbadoctets_hi), &(pstats-
> > > >mac_stx[1]),
> > > - sizeof(st
On Fri, Feb 10, 2023 at 1:13 PM Morten Brørup
wrote:
>
> > From: Sevincer, Abdullah [mailto:abdullah.sevin...@intel.com]
> > Sent: Thursday, 9 February 2023 19.50
> >
> > Acked: by abdullah.sevin...@intel.com
>
> Thanks.
>
> Patchwork didn't catch it due to formatting, but the point is obvious:
>
On 2/21/2024 4:36 PM, Ferruh Yigit wrote:
> On 2/20/2024 8:42 PM, Andrew Boyer wrote:
>> This patch series adds support to net/ionic for using UIO platform devices
>> as DPDK vdevs. This is used by client applications which run directly on
>> the AMD Pensando family of devices.
>>
>> The UIO code i
Bugfix: The vlan in the bulletin does not contain a VLAN header, only the
VLAN ID, so only copy 2 byte, not 4. The target structure has padding
after the field, so copying 2 byte too many is effectively harmless.
There is no need to backport this patch.
Use RTE_PTR_ADD where copying arrays to the
On 2/20/2024 3:58 AM, Jie Hai wrote:
> Hi, Ferruh,
>
> Thanks for your review.
>
> On 2024/2/7 22:15, Ferruh Yigit wrote:
>> On 2/6/2024 1:10 AM, Jie Hai wrote:
>>> From: Dengdui Huang
>>>
>>> When KEEP_CRC offload is enabled, some packets will be truncated and
>>> the CRC is still be stripped i
23/02/2024 09:38, Ferruh Yigit:
> On 2/23/2024 8:15 AM, Morten Brørup wrote:
> > Dear maintainers,
> >
> > Is it easier for you to spot if we ack a series in patch 0, patch 1, or the
> > last patch of the series? Or don't you have any preferences?
>
> When a patch is ack'ed, not cover letter (pa
Bugfix: The vlan in the bulletin does not contain a VLAN header, only the
VLAN ID, so only copy 2 byte, not 4. The target structure has padding
after the field, so copying 2 byte too many is effectively harmless.
There is no need to backport this patch.
Use RTE_PTR_ADD where copying arrays to the
In mlx5 PMD, handles to indirect connection tracking flow actions
are encoded in 32-bit unsigned integers as follows:
- Bits 31-29 - indirect action type.
- Bits 28-25 - port on which connection tracking action was created.
- Bits 24-0 - index of connection tracking object.
Macro defining a bit s
Patches 1 and 2 contain fixes for existing implementation of
connection tracking flow actions.
Patch 3 adds support for sharing connection tracking flow actions
between ports when ports' flow engines are configured with
RTE_FLOW_PORT_FLAG_SHARE_INDIRECT flag set.
Patch 4 is based on the previous
In mlx5 PMD, handles to indirect connection tracking flow actions
are encoded as 32-bit unsigned integers, where port ID is stored
in bits 28-25. Because of this, connection tracking flow actions
cannot be created on ports with IDs higher than 15.
This patch adds missing validation.
Fixes: 463170a
This patch removes the owner port index from integer
representation of indirect action handle in mlx5 PMD for conntrack
flow actions.
This index is not needed when HW Steering flow engine is enabled,
because either:
- port references its own indirect actions or,
- port references indirect actions
From: Suanming Mou
This commit adds cross port CT object sharing.
Shared CT object shares the same DevX objects, but allocate port's
own action locally. Once the CT object is shared between two flows
in different ports, the two flows use their own local action with
the same offset index.
The sh
This patchset adds support for two new QAT devices.
A new GEN3 device, and a GEN5 device, both of which have
wireless slice support for algorithms such as ZUC-256.
Symmetric, asymmetric and compression are all supported
for these devices.
v2:
- New patch added for gen5 device that reuses gen4
Add new gen3 QAT device ID.
This device has a wireless slice, but other gen3 devices do not, so we
must set a flag to indicate this wireless enabled device.
Capabilities for the device are slightly different from base gen3
capabilities, some are removed from the list for this device.
Symmetric, a
The new gen3 device handles wireless algorithms on wireless slices,
based on the device wireless slice support, set the required flags for
these algorithms to move slice.
One of the algorithms supported for the wireless slices is ZUC 256,
support is added for this, along with modifying the capabil
The new QAT GEN3 device uses new macros for CMAC values, rather than
using XCBC_MAC ones.
The wireless slice handles CMAC in the new gen3 device, and no key
precomputes are required by SW.
Signed-off-by: Ciara Power
---
drivers/common/qat/qat_adf/icp_qat_hw.h | 4 +++-
drivers/crypto/qat/qat_s
Add new gen5 QAT device ID.
This device has a wireless slice, so we must set a flag to indicate
this wireless enabled device.
Asides from the wireless slices and some extra capabilities for
wireless algorithms, the device is functionally the same as gen4 and can
reuse most functions and macros.
Sy
> -Original Message-
> From: Nayak, Nishikanta
> Sent: Wednesday, December 20, 2023 1:26 PM
> To: dev@dpdk.org
> Cc: Ji, Kai ; Power, Ciara ; Kusztal,
> ArkadiuszX ; Nayak, Nishikanta
> ; Thomas Monjalon ;
> Burakov, Anatoly
> Subject: [PATCH 1/4] common/qat: add files specific to GEN5
From: Satha Rao
Added CNXK APIs to get used txq descriptor count.
Signed-off-by: Satha Rao
---
Depends-on: series-30833 ("ethdev: support Tx queue used count")
v2:
Updated release notes and fixed API for CPT queues.
doc/guides/nics/features/cnxk.ini | 1 +
doc/guides/rel_notes/relea
Adds a devarg option to enable/disable ISM memory accesses
for reading packet count details. This option is disabled
by default, as ISM memory accesses effect throughput of
bigger size packets.
Signed-off-by: Vamsi Attunuru
---
doc/guides/nics/octeon_ep.rst | 12
drivers/net/oct
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
The current location used for __rte_aligned(a) for alignment of types
and variables is not compatible with MSVC. There is only a single
location accepted by both toolchains.
For variables standard C11 offers alignas(a) supported by conformant
compilers i.e. both MSVC and GCC.
For types the standa
The current location used for __rte_aligned(a) for alignment of types
and variables is not compatible with MSVC. There is only a single
location accepted by both toolchains.
For variables standard C11 offers alignas(a) supported by conformant
compilers i.e. both MSVC and GCC.
For types the standa
The current location used for __rte_aligned(a) for alignment of types
and variables is not compatible with MSVC. There is only a single
location accepted by both toolchains.
For variables standard C11 offers alignas(a) supported by conformant
compilers i.e. both MSVC and GCC.
For types the standa
The current location used for __rte_aligned(a) for alignment of types
and variables is not compatible with MSVC. There is only a single
location accepted by both toolchains.
For variables standard C11 offers alignas(a) supported by conformant
compilers i.e. both MSVC and GCC.
For types the standa
The current location used for __rte_aligned(a) for alignment of types
and variables is not compatible with MSVC. There is only a single
location accepted by both toolchains.
For variables standard C11 offers alignas(a) supported by conformant
compilers i.e. both MSVC and GCC.
For types the standa
The current location used for __rte_aligned(a) for alignment of types
and variables is not compatible with MSVC. There is only a single
location accepted by both toolchains.
For variables standard C11 offers alignas(a) supported by conformant
compilers i.e. both MSVC and GCC.
For types the standa
The current location used for __rte_aligned(a) for alignment of types
and variables is not compatible with MSVC. There is only a single
location accepted by both toolchains.
For variables standard C11 offers alignas(a) supported by conformant
compilers i.e. both MSVC and GCC.
For types the standa
The current location used for __rte_aligned(a) for alignment of types
and variables is not compatible with MSVC. There is only a single
location accepted by both toolchains.
For variables standard C11 offers alignas(a) supported by conformant
compilers i.e. both MSVC and GCC.
For types the standa
The current location used for __rte_aligned(a) for alignment of types
and variables is not compatible with MSVC. There is only a single
location accepted by both toolchains.
For variables standard C11 offers alignas(a) supported by conformant
compilers i.e. both MSVC and GCC.
For types the standa
The current location used for __rte_aligned(a) for alignment of types
and variables is not compatible with MSVC. There is only a single
location accepted by both toolchains.
For variables standard C11 offers alignas(a) supported by conformant
compilers i.e. both MSVC and GCC.
For types the standa
The current location used for __rte_aligned(a) for alignment of types
and variables is not compatible with MSVC. There is only a single
location accepted by both toolchains.
For variables standard C11 offers alignas(a) supported by conformant
compilers i.e. both MSVC and GCC.
For types the standa
The current location used for __rte_aligned(a) for alignment of types
and variables is not compatible with MSVC. There is only a single
location accepted by both toolchains.
For variables standard C11 offers alignas(a) supported by conformant
compilers i.e. both MSVC and GCC.
For types the standa
The current location used for __rte_aligned(a) for alignment of types
and variables is not compatible with MSVC. There is only a single
location accepted by both toolchains.
For variables standard C11 offers alignas(a) supported by conformant
compilers i.e. both MSVC and GCC.
For types the standa
The current location used for __rte_aligned(a) for alignment of types
and variables is not compatible with MSVC. There is only a single
location accepted by both toolchains.
For variables standard C11 offers alignas(a) supported by conformant
compilers i.e. both MSVC and GCC.
For types the standa
The current location used for __rte_aligned(a) for alignment of types
and variables is not compatible with MSVC. There is only a single
location accepted by both toolchains.
For variables standard C11 offers alignas(a) supported by conformant
compilers i.e. both MSVC and GCC.
For types the standa
The current location used for __rte_aligned(a) for alignment of types
and variables is not compatible with MSVC. There is only a single
location accepted by both toolchains.
For variables standard C11 offers alignas(a) supported by conformant
compilers i.e. both MSVC and GCC.
For types the standa
The current location used for __rte_aligned(a) for alignment of types
and variables is not compatible with MSVC. There is only a single
location accepted by both toolchains.
For variables standard C11 offers alignas(a) supported by conformant
compilers i.e. both MSVC and GCC.
For types the standa
The current location used for __rte_aligned(a) for alignment of types
and variables is not compatible with MSVC. There is only a single
location accepted by both toolchains.
For variables standard C11 offers alignas(a) supported by conformant
compilers i.e. both MSVC and GCC.
For types the standa
The current location used for __rte_aligned(a) for alignment of types
and variables is not compatible with MSVC. There is only a single
location accepted by both toolchains.
For variables standard C11 offers alignas(a) supported by conformant
compilers i.e. both MSVC and GCC.
For types the standa
The current location used for __rte_aligned(a) for alignment of types
and variables is not compatible with MSVC. There is only a single
location accepted by both toolchains.
For variables standard C11 offers alignas(a) supported by conformant
compilers i.e. both MSVC and GCC.
For types the standa
The current location used for __rte_aligned(a) for alignment of types
and variables is not compatible with MSVC. There is only a single
location accepted by both toolchains.
For variables standard C11 offers alignas(a) supported by conformant
compilers i.e. both MSVC and GCC.
For types the standa
The current location used for __rte_aligned(a) for alignment of types
and variables is not compatible with MSVC. There is only a single
location accepted by both toolchains.
For variables standard C11 offers alignas(a) supported by conformant
compilers i.e. both MSVC and GCC.
For types the standa
The current location used for __rte_aligned(a) for alignment of types
and variables is not compatible with MSVC. There is only a single
location accepted by both toolchains.
For variables standard C11 offers alignas(a) supported by conformant
compilers i.e. both MSVC and GCC.
For types the standa
The current location used for __rte_aligned(a) for alignment of types
and variables is not compatible with MSVC. There is only a single
location accepted by both toolchains.
For variables standard C11 offers alignas(a) supported by conformant
compilers i.e. both MSVC and GCC.
For types the standa
The current location used for __rte_aligned(a) for alignment of types
and variables is not compatible with MSVC. There is only a single
location accepted by both toolchains.
For variables standard C11 offers alignas(a) supported by conformant
compilers i.e. both MSVC and GCC.
For types the standa
The current location used for __rte_aligned(a) for alignment of types
and variables is not compatible with MSVC. There is only a single
location accepted by both toolchains.
For variables standard C11 offers alignas(a) supported by conformant
compilers i.e. both MSVC and GCC.
For types the standa
The current location used for __rte_aligned(a) for alignment of types
and variables is not compatible with MSVC. There is only a single
location accepted by both toolchains.
For variables standard C11 offers alignas(a) supported by conformant
compilers i.e. both MSVC and GCC.
For types the standa
The current location used for __rte_aligned(a) for alignment of types
and variables is not compatible with MSVC. There is only a single
location accepted by both toolchains.
For variables standard C11 offers alignas(a) supported by conformant
compilers i.e. both MSVC and GCC.
For types the standa
The current location used for __rte_aligned(a) for alignment of types
and variables is not compatible with MSVC. There is only a single
location accepted by both toolchains.
For variables standard C11 offers alignas(a) supported by conformant
compilers i.e. both MSVC and GCC.
For types the standa
The current location used for __rte_aligned(a) for alignment of types
and variables is not compatible with MSVC. There is only a single
location accepted by both toolchains.
For variables standard C11 offers alignas(a) supported by conformant
compilers i.e. both MSVC and GCC.
For types the standa
The current location used for __rte_aligned(a) for alignment of types
and variables is not compatible with MSVC. There is only a single
location accepted by both toolchains.
For variables standard C11 offers alignas(a) supported by conformant
compilers i.e. both MSVC and GCC.
For types the standa
The current location used for __rte_aligned(a) for alignment of types
and variables is not compatible with MSVC. There is only a single
location accepted by both toolchains.
For variables standard C11 offers alignas(a) supported by conformant
compilers i.e. both MSVC and GCC.
For types the standa
The current location used for __rte_aligned(a) for alignment of types
and variables is not compatible with MSVC. There is only a single
location accepted by both toolchains.
For variables standard C11 offers alignas(a) supported by conformant
compilers i.e. both MSVC and GCC.
For types the standa
The current location used for __rte_aligned(a) for alignment of types
and variables is not compatible with MSVC. There is only a single
location accepted by both toolchains.
For variables standard C11 offers alignas(a) supported by conformant
compilers i.e. both MSVC and GCC.
For types the standa
The current location used for __rte_aligned(a) for alignment of types
and variables is not compatible with MSVC. There is only a single
location accepted by both toolchains.
For variables standard C11 offers alignas(a) supported by conformant
compilers i.e. both MSVC and GCC.
For types the standa
The current location used for __rte_aligned(a) for alignment of types
and variables is not compatible with MSVC. There is only a single
location accepted by both toolchains.
For variables standard C11 offers alignas(a) supported by conformant
compilers i.e. both MSVC and GCC.
For types the standa
The current location used for __rte_aligned(a) for alignment of types
and variables is not compatible with MSVC. There is only a single
location accepted by both toolchains.
For variables standard C11 offers alignas(a) supported by conformant
compilers i.e. both MSVC and GCC.
For types the standa
The current location used for __rte_aligned(a) for alignment of types
and variables is not compatible with MSVC. There is only a single
location accepted by both toolchains.
For variables standard C11 offers alignas(a) supported by conformant
compilers i.e. both MSVC and GCC.
For types the standa
The current location used for __rte_aligned(a) for alignment of types
and variables is not compatible with MSVC. There is only a single
location accepted by both toolchains.
For variables standard C11 offers alignas(a) supported by conformant
compilers i.e. both MSVC and GCC.
For types the standa
Hi Juraj,
Thank you for your review!
On 29/01/2024 11:47, Juraj Linkeš wrote:
I didn't see the mutual exclusion being enforced in the code. From
what I can tell, I could pass both --tarball FILEPATH and --revision
and the former would be used without checking the latter.
Yep, it is enforced i
On 29/01/2024 13:04, Juraj Linkeš wrote:
I'm curious, what exactly is confusing about the message?
Unfortunately a bit too much time has passed... but if I remember
correctly I think that given the great amount of arguments, whenever the
message is printed a bit too much information is given
On 29/01/2024 13:10, Juraj Linkeš wrote:
Here's I'd add logged additionally as an error, as this sounds as if
we're changing debug to error
That is also a way of doing this, but an error is an error. If we wanted
to log the same thing in debug and error, then when we go read the debug
we get
February 22, 2024
#
Attendees
1. Patrick Robb
2. Ali Alnubani
3. Paul Szczepanek
4. Juraj Linkeš
5. Luca Vizzarro
#
Minutes
85 matches
Mail list logo
