Re: [PATCH] dts: automatically bring up link on interfaces

Reviewed-by: Paul Szczepanek

Re: compilation|FAILURE| pw(150482) sid(34444) job(PER_PATCH_BUILD14715)[v6, 25/25] net/intel: extract common Rx vector criteria

On Sun, Jan 26, 2025 at 01:45:54AM +, Liao, TingtingX wrote: >Sorry. There is no error with this series. > >The error is caused by the CI doesn't apply any changes with doc/*. > >Community decided to exclude doc/*, as doc/* change frequently, >especially the release notes, ca

Re: [PATCH dpdk] telemetry-exporter: listen on loopback by default

On Mon, Jan 27, 2025 at 12:51:44PM +0100, Robin Jarry wrote: > Fix the following warning reported by Coverity: > > Defect type: SIGMA.insecure_network_bind: > > dpdk-stable-24.11.1/usertools/dpdk-telemetry-exporter.py:278: > > Sigma main event: The HTTP server binds to all network interfaces by >

Re: [PATCH v2] build: force gcc to initialize padding bits

On Fri, Jan 24, 2025 at 10:26:48AM -0800, Stephen Hemminger wrote: > With GCC 15, the compiler has changed the default behavior when > initialization is used for aggregate variables. The new default > is to follow the standard (C23) and not initialize everything by > default. This breaks assumption

Re: [PATCH] build: force gcc to initialize padding bits

On Fri, Jan 24, 2025 at 10:37:48AM -0800, Stephen Hemminger wrote: > On Fri, 24 Jan 2025 09:38:20 + > Bruce Richardson wrote: > > > > > > > > Does this flag give us additional guarantees of padding being > > zero-initialized that were there before? From my reading of the gcc doc[1], > > "

[PATCH] net/mlx5: fix leak in HWS flow counter action

This was caught by our internal covscan. mp_name can be leaked in case of errors. Fixes: 4d368e1da3a4 ("net/mlx5: support flow counter action for HWS") Cc: sta...@dpdk.org Signed-off-by: David Marchand --- drivers/net/mlx5/mlx5_hws_cnt.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)

[PATCH dpdk] telemetry-exporter: listen on loopback by default

Fix the following warning reported by Coverity: Defect type: SIGMA.insecure_network_bind: > dpdk-stable-24.11.1/usertools/dpdk-telemetry-exporter.py:278: > Sigma main event: The HTTP server binds to all network interfaces by > setting the IP address to "", `0.0.0.0`, `::`, or `::0`. > This may exp

RE: [PATCH 1/2] common/idpf: enable AVX2 for single queue Rx

Hi, Thanks for the review and feedback. Below I have addressed your comments inline. -Original Message- From: Richardson, Bruce Sent: Monday, January 20, 2025 7:46 PM To: Wani, Shaiq Cc: dev@dpdk.org; Singh, Aman Deep Subject: Re: [PATCH 1/2] common/idpf: enable AVX2 for single queu

RE: [PATCH 2/2] common/idpf: enable AVX2 for single queue Tx

Hi, Thanks for your review and feedback. Below I have addressed your comments inline. -Original Message- From: Richardson, Bruce Sent: Monday, January 20, 2025 7:53 PM To: Wani, Shaiq Cc: dev@dpdk.org; Singh, Aman Deep Subject: Re: [PATCH 2/2] common/idpf: enable AVX2 for single queu

RE: [EXTERNAL] [PATCH 1/2] trace: support expression for blob length

> -Original Message- > From: David Marchand > Sent: Friday, January 24, 2025 9:44 PM > To: dev@dpdk.org > Cc: Jerin Jacob ; Sunil Kumar Kori ; > Tyler Retzlaff ; Thomas Monjalon > ; Ferruh Yigit ; Andrew > Rybchenko > Subject: [EXTERNAL] [PATCH 1/2] trace: support expression for blob l

RE: [PATCH v2 1/2] lib/cryptodev: avoid implicit conversion to 64 bit number

> From: Andre Muezerie [mailto:andre...@linux.microsoft.com] > Sent: Monday, 27 January 2025 17.04 > > MSVC issues the warning below: > > ../lib/cryptodev/rte_cryptodev.c(623): warning C4334: '<<': > result of 32-bit shift implicitly converted to 64 bits > (was 64-bit shift intended?) >

RE: [PATCH v2 2/2] lib/hash: avoid implicit conversion to 64 bit number

> From: Andre Muezerie [mailto:andre...@linux.microsoft.com] > Sent: Monday, 27 January 2025 17.04 > > MSVC issues the warnings below: > > 1) ../lib/hash/rte_thash_gf2_poly_math.c(128): warning C4334: '<<': > result of 32-bit shift implicitly converted to 64 bits > (was 64-bit shift inten

[RFC 0/7] Introduce FreeBSD macros for SAFE iteration

This series adds common macros for safe iteration over lists. It is a subset copy of the macros from FreeBSD that are missing from the Linux header sys/queue.h Chose this over several other options: - let each driver define their own as needed. One Intel driver got it wrong, others will as w

Re: [RFC 0/7] Introduce FreeBSD macros for SAFE iteration

On Mon, Jan 27, 2025 at 10:03:54AM -0800, Stephen Hemminger wrote: > This series adds common macros for safe iteration over lists. > It is a subset copy of the macros from FreeBSD that are > missing from the Linux header sys/queue.h > > Chose this over several other options: > - let each driver

Re: [RFC 0/7] Introduce FreeBSD macros for SAFE iteration

On Mon, 27 Jan 2025 18:16:18 + Bruce Richardson wrote: > On Mon, Jan 27, 2025 at 10:03:54AM -0800, Stephen Hemminger wrote: > > This series adds common macros for safe iteration over lists. > > It is a subset copy of the macros from FreeBSD that are > > missing from the Linux header sys/queue

Re: [PATCH dpdk] telemetry-exporter: listen on loopback by default

Bruce Richardson, Jan 27, 2025 at 15:39: > On Mon, Jan 27, 2025 at 12:51:44PM +0100, Robin Jarry wrote: >> Fix the following warning reported by Coverity: >> >> Defect type: SIGMA.insecure_network_bind: >> > dpdk-stable-24.11.1/usertools/dpdk-telemetry-exporter.py:278: >> > Sigma main event: The H

[PATCH v2 2/2] lib/hash: avoid implicit conversion to 64 bit number

MSVC issues the warnings below: 1) ../lib/hash/rte_thash_gf2_poly_math.c(128): warning C4334: '<<': result of 32-bit shift implicitly converted to 64 bits (was 64-bit shift intended?) The code would be better off by using 64 bit numbers to begin with. That eliminates the need for a conver

[PATCH v2 1/2] lib/cryptodev: avoid implicit conversion to 64 bit number

MSVC issues the warning below: ../lib/cryptodev/rte_cryptodev.c(623): warning C4334: '<<': result of 32-bit shift implicitly converted to 64 bits (was 64-bit shift intended?) The code would be better off by using 64 bit numbers to begin with. That eliminates the need for a conversion to 6

[PATCH] doc: reword sample application guides

I have revised these sections to suit the template, but also, for punctuation, clarity, and removing repitition when necessary. Signed-off-by: Nandini Persad --- doc/guides/sample_app_ug/dist_app.rst | 24 +-- .../sample_app_ug/eventdev_pipeline.rst | 20 +-- doc/guides/sample_ap

Re: [PATCH v1 0/2] Update Base code for TXPP Implementation

On Fri, Jan 17, 2025 at 09:39:36AM +, Soumyadeep Hore wrote: > Updating Base Code for TXPP Feature Implementation. > > Paul Greenwalt (2): > net/ice: add tstamp descriptor > net/ice: add Tx Time queue context configuration support > > drivers/net/ice/base/ice_adminq_cmd.h | 55 ++

RE: [PATCH v3] mbuf: add fast free bulk and raw alloc bulk functions

> When putting an mbuf back into its mempool, there are certain requirements > to the mbuf. Specifically, some of its fields must be initialized. > > These requirements are in fact invariants about free mbufs, held in > mempools, and thus also apply when allocating an mbuf from a mempool. > With

[RFC 7/7] raw/ifpga: use EAL version of TAILQ_FOREACH_SAFE

Prefer the EAL version over local version of macro. Signed-off-by: Stephen Hemminger --- drivers/raw/ifpga/base/opae_osdep.h | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/raw/ifpga/base/opae_osdep.h b/drivers/raw/ifpga/base/opae_osdep.h index e35a21c80e..b483d00a54 100644 --- a/dr

[RFC 1/7] eal: add queue macro extensions from FreeBSD

The Linux version of sys/queue.h is frozen at an older version and is missing the _SAFE macro variants. Several drivers started introducing the own workarounds for this. Should be handled in EAL. Signed-off-by: Stephen Hemminger --- lib/eal/include/meson.build | 3 +- lib/eal/include/rte_queue

[RFC 2/7] net/qede: fix use after free

The loop cleaning up flowdir resources was using SLIST_FOREACH but the inner loop would call rte_free. Found by building with address sanitizer undefined check. Also remove needless initialization, and null check. Fixes: f5765f66f9bb ("net/qede: refactor flow director into generic aRFS") Cc: shah

[RFC 5/7] net/iavf: replace local version of TAILQ_FOREACH_SAFE

Now in EAL as rte_queue.h Signed-off-by: Stephen Hemminger --- drivers/net/iavf/iavf_vchnl.c | 8 +--- 1 file changed, 1 insertion(+), 7 deletions(-) diff --git a/drivers/net/iavf/iavf_vchnl.c b/drivers/net/iavf/iavf_vchnl.c index 065ab3594c..c9684ae189 100644 --- a/drivers/net/iavf/iavf_vc

[RFC 3/7] bus/fslmc: fix use after free

The cleanup loop would deference the dpio_dev after freeing. Use TAILQ_FOREACH_SAFE to fix that. Found by building with sanitizer undefined flag. Fixes: e55d0494ab98 ("bus/fslmc: support secondary process") Cc: shreyansh.j...@nxp.com Cc: sta...@dpdk.org Signed-off-by: Stephen Hemminger --- drive

[RFC 6/7] vhost: replace open coded TAILQ_FOREACH_SAFE

Proper macro is now in EAL rte_queue.h use it instead. Signed-off-by: Stephen Hemminger --- lib/vhost/socket.c | 11 ++- 1 file changed, 2 insertions(+), 9 deletions(-) diff --git a/lib/vhost/socket.c b/lib/vhost/socket.c index 05a7e5902f..625ed08b7c 100644 --- a/lib/vhost/socket.c +++

[RFC 4/7] net/bnxt: fix use after free

The filter cleanup loop was using STAILQ_FOREACH and rte_free and would dereference the filter after free. Found by build with -Dbsanitize=address,undefined Fixes: e8fe0e067b68 ("net/bnxt: fix allocation of PF info struct") Cc: ajit.khapa...@broadcom.com Cc: sta...@dpdk.org Signed-off-by: Stephe

Re: [RFC 4/7] net/bnxt: fix use after free

On Mon, Jan 27, 2025 at 10:08 AM Stephen Hemminger wrote: > > The filter cleanup loop was using STAILQ_FOREACH and rte_free > and would dereference the filter after free. > > Found by build with -Dbsanitize=address,undefined > > Fixes: e8fe0e067b68 ("net/bnxt: fix allocation of PF info struct") >

[PATCH v3 1/3] lib/cryptodev: avoid implicit conversion to 64 bit number

MSVC issues the warning below: ../lib/cryptodev/rte_cryptodev.c(623): warning C4334: '<<': result of 32-bit shift implicitly converted to 64 bits (was 64-bit shift intended?) The code would be better off by using 64 bit numbers to begin with. That eliminates the need for a conversion to 6

[PATCH v3 3/3] drivers/crypto: use RTE_BIT64 in initializations of hash_algos

This was found during code review of similar issues. Signed-off-by: Andre Muezerie --- drivers/crypto/cnxk/cnxk_cryptodev_capabilities.c | 4 ++-- drivers/crypto/openssl/rte_openssl_pmd_ops.c | 4 ++-- 2 files changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/crypto/cnxk/cnxk_c

[PATCH v3 2/3] lib/hash: avoid implicit conversion to 64 bit number

MSVC issues the warnings below: 1) ../lib/hash/rte_thash_gf2_poly_math.c(128): warning C4334: '<<': result of 32-bit shift implicitly converted to 64 bits (was 64-bit shift intended?) The code would be better off by using 64 bit numbers to begin with. That eliminates the need for a conver

Re: [PATCH v2 1/2] lib/cryptodev: avoid implicit conversion to 64 bit number

On Mon, Jan 27, 2025 at 06:14:47PM +0100, Morten Brørup wrote: > > From: Andre Muezerie [mailto:andre...@linux.microsoft.com] > > Sent: Monday, 27 January 2025 17.04 > > > > MSVC issues the warning below: > > > > ../lib/cryptodev/rte_cryptodev.c(623): warning C4334: '<<': > > result of 32-bit

RE: [RFC 0/7] Introduce FreeBSD macros for SAFE iteration

> From: Stephen Hemminger [mailto:step...@networkplumber.org] > Sent: Monday, 27 January 2025 19.44 > > On Mon, 27 Jan 2025 18:16:18 + > Bruce Richardson wrote: > > > On Mon, Jan 27, 2025 at 10:03:54AM -0800, Stephen Hemminger wrote: > > > This series adds common macros for safe iteration ov

Re: [RFC 0/7] Introduce FreeBSD macros for SAFE iteration

On Mon, 27 Jan 2025 20:29:55 +0100 Morten Brørup wrote: > > From: Stephen Hemminger [mailto:step...@networkplumber.org] > > Sent: Monday, 27 January 2025 19.44 > > > > On Mon, 27 Jan 2025 18:16:18 + > > Bruce Richardson wrote: > > > > > On Mon, Jan 27, 2025 at 10:03:54AM -0800, Stephen H

[PATCH 2/4] net/netvsc: remove RTE device if all its net devices are removed

From: Long Li An RTE device can have multiple Ethernet devices. On hot plug events, it can't be removed until all its Ethernet devices have been removed. Fixes: a2a23a794b3a ("net/netvsc: support VF device hot add/remove") Cc: sta...@dpdk.org Signed-off-by: Long Li --- drivers/net/netvsc/hn_vf

[PATCH 4/4] net/netvsc: cache device parameters for hot plug events

From: Long Li If a device is hot removed and hot plugged, it needs the same driver parameters that are passed to EAL. However, during device removal, all EAL driver parameters are freed as part of the cleanup. Cache those driver parameters for future hot plug events. Because we don't know which

[PATCH 3/4] net/netvsc: log error on failure to switch data path

From: Long Li There is no recovery code path if netvsc failed to switch data path. Log an error in this case for troubleshooting. Signed-off-by: Long Li --- drivers/net/netvsc/hn_vf.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/drivers/net/netvsc/hn_vf.c b/drivers

[PATCH 1/4] net/netvsc: scan all net devices under the PCI device

From: Long Li The current code has the wrong assumption that a PCI device can have only one Ethernet device. This is not correct as a PCI device can be multi functional and have multiple Ethernet devices. Fix this by scanning all the devices under a PCI device. Fixes: a2a23a794b3a ("net/netvsc:

RE: [PATCH v6 00/25] Reduce code duplication across Intel NIC drivers

This patchset attempts to reduce the amount of code duplication across a number of Intel NIC drivers, specifically: ixgbe, i40e, iavf, and ice. As part of this process of deduplication, and in preparation for further cleanup work, it moves all existing Intel drivers to a net/intel directory, w

[PATCH 3/3] net/mlx5: fix flow flush for non-template flows

Fix flow flush for non template flows on top of HWS, in another fix it was added return after releasing template flows. Need to drop the return in order to release non template list of flows. Fixes: 1ea333d2de22 ("net/mlx5: fix Rx queue reference count in flushing flows") Cc: sta...@dpdk.org Signe

[PATCH 0/3] Non template to HWS fixes

Few fixes for non template mode on top of HWS. Maayan Kashani (3): net/mlx5: fix limitation of actions per rule net/mlx5: fix crash in non template metadata split net/mlx5: fix flow flush for non-template flows drivers/net/mlx5/mlx5_flow.c | 1 - drivers/net/mlx5/mlx5_flow.h |

[PATCH 1/3] net/mlx5: fix limitation of actions per rule

HWS implementation added a limitation of 16 actions per rule, which was incompatible with SWS limitation of 32 actions per rule. Changing the hard coded limitation in PMD to 32. Fixes: f13fab23922b ("net/mlx5: add flow jump action") Signed-off-by: Maayan Kashani Acked-by: Dariusz Sosnowski ---

[PATCH 2/3] net/mlx5: fix crash in non template metadata split

For switch dev mode, there is a rule split in case of using mark action. First rule will have the mark action, tag it with rule ID number and jump to the second rule that matches the tag and perform the rest of the actions (like RSS or queue). First, fix the crash when accessing RSS queue[0] inste

RE: [PATCH v3 3/3] drivers/crypto: use RTE_BIT64 in initializations of hash_algos

> From: Andre Muezerie [mailto:andre...@linux.microsoft.com] > Sent: Monday, 27 January 2025 20.33 > > This was found during code review of similar issues. > > Signed-off-by: Andre Muezerie > --- Reviewed-by: Morten Brørup CNXK crypto & OpenSSL crypto driver maintainers, please review/ack.

RE: [PATCH v3 3/3] drivers/crypto: use RTE_BIT64 in initializations of hash_algos

> > From: Andre Muezerie [mailto:andre...@linux.microsoft.com] > > Sent: Monday, 27 January 2025 20.33 > > > > This was found during code review of similar issues. > > > > Signed-off-by: Andre Muezerie > > --- > > Reviewed-by: Morten Brørup