RE: [EXTERNAL] [PATCH v2 1/9] crypto/zsda: add skeleton

> diff --git a/doc/guides/compressdevs/zsda.rst > b/doc/guides/compressdevs/zsda.rst > index 25b7884535..34cbf235af 100644 > --- a/doc/guides/compressdevs/zsda.rst > +++ b/doc/guides/compressdevs/zsda.rst > @@ -174,6 +174,15 @@ e.g. for the 1cf2 device:: > Use ``modprobe vfio-pci disable_denylist=

Re: [PATCH] net/gve: remove gve-specific PCI revision ID macros

Patch doesn't apply to the main branch of dpdk-next-net: https://mails.dpdk.org/archives/test-report/2025-May/877522.html It seems like the diffbase patch only exists in the for-main branch. When is for-main expected to be merged into main, and should we be building against for-main or main? Simil

[PATCH] net/gve: remove gve-specific PCI revision ID macros

Commit 5feee68de99e ("pci: define more standard register offsets") adds a generic offset macro for the PCI revision ID, among a number of other standard PCI config fields. Update GVE to make use of these macros instead of defining its own. Signed-off-by: Joshua Washington --- drivers/net/gve/bas

[PATCH v4 0/3] lcore options cleanup

This v4 scales back some of the work done in the previous versions, since more options need to be looked at for the core handling. For now, then this patchset is reduced to some basic cleanup before any more serious work is done. * marks the old coremask parameter (-c) and service core mask (-s) a

Re: [PATCH v3 4/4] eal: add option for auto-mapping cpu ids to low lcore ids

On Fri, May 02, 2025 at 04:11:34PM +0100, Bruce Richardson wrote: > When attempting to run DPDK with cpu ids > RTE_MAX_LCORE, it can be > awkward to build up a command-line parameter specifying the cpu to lcore > mappings core-by-core. To simplify things for the common case, add in > the -L, --lcor

[PATCH v4 2/3] eal: merge corelist and core mapping options

The "-l" EAL parameter supported a subset of the features that were provided by the "--lcores" long option. There is no need to have two different options with different behaviour in this case, so we can just eliminate the special-case handling for "-l", and have it as a shortened form of "--lcores

[PATCH v4 3/3] doc: provide examples of using lcores EAL parameter

The "--lcores" EAL parameter has a very powerful syntax that can be used to provide precise control over lcore mappings. The docs however, only provided a minimal description of what it can do. Augment the docs by providing some examples of use of the option, and what the resulting core mappings wo

[PATCH v4 1/3] eal: deprecate old coremask-based EAL parameters

As the number of cores/cpus on platforms has increased over the years, the use of coremasks rather than core-lists for identifying DPDK cores has become more and more unwieldy. At this point, let's deprecate the coremask-based EAL parameters for future removal, and point users to the core-list base

DPDK Release Status Meeting 2025-05-13

Release status meeting minutes 2025-05-13 = Agenda: * Release Dates * Subtrees * Roadmaps * LTS * Defects * Opens Participants: * Broadcom * ARM * Intel * Marvell * Microsoft * Nvidia * Red Hat Release Dates - The following are the proposed w

Re: [PATCH 1/4] bus/pci: Use force-noreplace flag when mapping PCI resources

On 5/6/2025 7:40 PM, Jake Freeland wrote: When mapping PCI resources in secondary processes, use the RTE_MAP_FORCE_ADDRESS_NOREPLACE flag to indicate that the mapping must be made at the provided address. Without this flag, the kernel might return a different address for the mapping, even if the

lcore vs control thread function return type

Why do control thread functions return uint32_t [1], when lcore thread functions return int [2]? https://elixir.bootlin.com/dpdk/v25.03/source/lib/eal/include/rte_thread.h#L53 https://elixir.bootlin.com/dpdk/v25.03/source/lib/eal/include/rte_launch.h#L31

Re: [PATCH] net/mlx5/hws: fix send queue drain on FW WQE destroy

Hi, On 27/04/2025 2:28 PM, Maayan Kashani wrote: Queue sync operation was skipped on rule destroy. Unlike on fw wqe rule create in which both fence and notify_hw are set to true, on destroy fence was set to false causing previous queue operation to be stuck in the queue forever. Example: ru

[PATCH v2] bus/vdev: revert fix devargs after multi-process bus scan

This patch reverts commit f5b2eff0847d ("bus/vdev: fix devargs after multi-process bus scan") With current code, we do not add devargs to devargs list when we add a vdev in secondary process (because `init` flag is set to `false`). Because of this, when we do vdev_uninit, we call rte_devargs_remo

[PATCH v2] build: automatically report minimum meson version

Add a script to buildtools to report the minimum meson version given in our meson.build file. Then use this script in two ways: 1. in the .ci/linux-setup.sh script, use the auto-determined minimum version to set up the CI, rather than hard-coding it. 2. in meson.build call the script to report