* Re: [PATCH] app: remove use of strncpy
From: Thomas Monjalon @ 2026-07-11 22:57 UTC (permalink / raw)
To: Bruce Richardson
Cc: dev, stable, Kai Ji, Cheng Jiang, Chengwen Feng, Jerin Jacob,
Ori Kam, Aman Singh, Michal Kobylinski, Piotr Azarewicz,
Marcin Kerlin, Slawomir Mrozowicz, Declan Doherty,
Aleksander Gajewski, Pablo de Lara, Guduri Prathyusha,
Harry van Haaren, Morten Brørup, Jiayu Hu, Yuan Wang,
Anoob Joseph, Xiaoyu Min, Xueming Li, Yuval Avnery
In-Reply-To: <20260623145028.711712-1-bruce.richardson@intel.com>
23/06/2026 16:50, Bruce Richardson:
> Use of strncpy is not recommended, so replace it with strlcpy or memcpy
> as appropriate.
>
> Fixes: f8be1786b1b8 ("app/crypto-perf: introduce performance test application")
> Fixes: 8ecd4048ba5d ("app/crypto-perf: fix string not null terminated")
> Fixes: 0add6c27cd7c ("app/testeventdev: define the test options")
> Fixes: 623dc9364dc6 ("app/dma-perf: introduce DMA performance test")
> Fixes: 1e8a4e97b057 ("app/testpmd: add flow dump command")
> Fixes: de06137cb295 ("app/regex: add RegEx test application")
> Cc: stable@dpdk.org
>
> Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH v2] app/dma_perf: skip case if worker maps to main lcore
From: Thomas Monjalon @ 2026-07-11 23:14 UTC (permalink / raw)
To: Rupesh Chiluka
Cc: dev, stable, honest.jiang, gakhil, anoobj, ktejasree,
fengchengwen
In-Reply-To: <02096633-cb82-4c04-9e39-00638146c11b@huawei.com>
24/06/2026 08:09, fengchengwen:
> On 6/24/2026 1:42 PM, Rupesh Chiluka wrote:
> > When a configured worker lcore is same as EAL main lcore, the main
> > thread calls `rte_eal_remote_launch()` on itself and then waits for
> > `worker_info.ready_flag`. The worker function cannot run on the main
> > lcore while the main thread is blocked in that loop, and the test hangs.
> >
> > Reject such cases early in the `run_test()`.
> >
> > Fixes: 623dc9364dc6 ("app/dma-perf: introduce DMA performance test")
> > CC: stable@dpdk.org
> >
> > Signed-off-by: Rupesh Chiluka <rchiluka@marvell.com>
>
> Acked-by: Chengwen Feng <fengchengwen@huawei.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH v3 0/6] examples: remove MAX_TX_QUEUE_PER_PORT
From: Thomas Monjalon @ 2026-07-12 0:17 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: dev, Bruce Richardson, sivaprasad.tummala
In-Reply-To: <aj4o9IOCeg7qWiNs@bricha3-mobl1.ger.corp.intel.com>
26/06/2026 09:23, Bruce Richardson:
> On Thu, Jun 25, 2026 at 10:46:50AM -0700, Stephen Hemminger wrote:
> > This is an old set of patches that removes the use of MAX_TX_QUEUE_PER_PORT
> > in all the examples.
> >
> > Sivaprasad Tummala (5):
> > examples/l3fwd-graph: remove redundant Tx queue limit
> > examples/l3fwd: remove redundant Tx queue limit
> > examples/ip_fragmentation: remove redundant Tx queue limit
> > examples/ip_reassembly: remove redundant Tx queue limit
> > examples/ipv4_multicast: remove redundant Tx queue limit
> >
> > Stephen Hemminger (1):
> > examples: remove unused define
> >
> Series-acked-by: Bruce Richardson <bruce.richardson@intel.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH v2] examples/l3fwd: dynamic NUMA-aware alloc lcore_conf
From: Thomas Monjalon @ 2026-07-12 0:36 UTC (permalink / raw)
To: Chengwen Feng; +Cc: stephen, dev
In-Reply-To: <20260624032357.2153-1-fengchengwen@huawei.com>
24/06/2026 05:23, Chengwen Feng:
> Currently lcore_conf is a global static array. When multiple
> ports/lcores are distributed across different NUMA nodes, datapath
> suffers from severe cross-NUMA memory access penalty.
>
> On Kunpeng platform, sizeof(struct lcore_conf) reaches 133760 bytes.
> Such a huge per-lcore structure significantly amplifies cross-NUMA
> overhead in multi-port multi-NUMA deployment scenarios.
>
> This commit refactors lcore_conf to pointer array and implements
> per-lcore NUMA-aware hugepage allocation, allocating each lcore's
> configuration on its local socket to eliminate remote memory access.
>
> Signed-off-by: Chengwen Feng <fengchengwen@huawei.com>
There is an issue with this change as found by AI:
init_lcore_conf() is called before parse_args(),
so the new lcore_conf allocation happens before --no-numa can set numa_on = 0.
As a result, init_lcore_conf() always uses rte_lcore_to_socket_id()
and allocates each lcore_conf on the lcore's NUMA socket,
even when the user requested non-NUMA allocation.
This can also make startup fail if an enabled lcore is on a socket
without hugepage memory, although --no-numa should force allocations on socket 0.
init_lcore_conf() should be moved after parse_args(), and it should use something like:
socketid = numa_on ? rte_lcore_to_socket_id(lcore_id) : 0;
^ permalink raw reply
* Re: [PATCH] config/x86: enable compatibility with muon-build
From: Thomas Monjalon @ 2026-07-12 0:47 UTC (permalink / raw)
To: Richardson, Bruce; +Cc: dev@dpdk.org, Loftus, Ciara
In-Reply-To: <DM3PPF7D18F34A1A9A7381CA38881194F948E2D2@DM3PPF7D18F34A1.namprd11.prod.outlook.com>
22/04/2026 13:02, Loftus, Ciara:
> > Subject: [PATCH] config/x86: enable compatibility with muon-build
> >
> > Muon[1] is a reimplementation of meson in C, and in some ways is rather
> > stricter than meson in processing the build files. Make a few small
> > changes to the meson.build files to improve muon compatibility without
> > affecting meson:
> > * when checking a list of compiler args always use has_multi_arguments
> > rather than has_argument, even if list only contains one item.
> > * when putting lists of compiler args in message output, explicitly
> > convert to a string for output using ','.join().
> >
> > [1] https://github.com/muon-build/muon
> >
> > Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
>
> I tested this out with both muon built from source and muon downloaded
> as a package ("muon-meson"). Only the version from source worked, as the
> package version was missing some features required for building DPDK. I
> encountered the same issue with the cnxk driver you flagged. Build was
> successful after disabling. I think it makes sense to make these
> changes.
>
> Acked-by: Ciara Loftus <ciara.loftus@intel.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH] usertools/dpdk-devbind: improve query performance on BSD
From: Thomas Monjalon @ 2026-07-12 0:56 UTC (permalink / raw)
To: Bruce Richardson; +Cc: dev
In-Reply-To: <20260629125929.2331943-1-bruce.richardson@intel.com>
29/06/2026 14:59, Bruce Richardson:
> The time taken on FreeBSD to run the status command from dpdk-devbind
> was exceptionally long. When run on a real system with lots of
> devices, the original code took over 80 seconds in some cases to produce
> the output of "dpdk-devbind.py -s". (Time on BSD VMs is quicker as they
> tend not to have so many hardware devices, which is why this may not
> have been noticed before.)
>
> Rework the processing to avoid doing so many subprocess calls to
> pciconf; use one call to get info on all devices rather than an
> individual call per-device. On the same HW as before, it now takes a
> fraction of a second, rather than >80 seconds.
>
> Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH v3 2/3] usertools/telemetry: support using aliases for long commands
From: Thomas Monjalon @ 2026-07-12 10:12 UTC (permalink / raw)
To: Bruce Richardson; +Cc: dev, fengchengwen
In-Reply-To: <20260609161400.3661268-3-bruce.richardson@intel.com>
09/06/2026 18:13, Bruce Richardson:
> Similarly to how shell aliases work, allow specifying of short alias
> commands for dpdk-telemetry.py script. The aliases are read from
> "$HOME/.dpdk_telemetry_aliases" at startup.
I don't like polluting the home directory of the user.
We already have these files and directories:
~/.config/dpdk/devel.config
~/.dpdk_telemetry_aliases
~/dpdk-traces/
~/dpdk_graph_pcap_capture_XXXXXX.pcapng
/usr/share/dpdk/telemetry-endpoints
I think ~/.config/dpdk/ is the best place for our config files.
It is not blocking the series but we should work on unifying these files.
^ permalink raw reply
* Re: [PATCH v3 0/3] extend interactive telemetry script
From: Thomas Monjalon @ 2026-07-12 14:23 UTC (permalink / raw)
To: Bruce Richardson; +Cc: dev, fengchengwen
In-Reply-To: <97afe9be-41c0-44da-b144-0fddeb7374e5@huawei.com>
> > Bruce Richardson (3):
> > usertools/telemetry: add a FOREACH command
> > usertools/telemetry: support using aliases for long commands
> > usertools/telemetry: add help support
>
> Series-acked-by: Chengwen Feng <fengchengwen@huawei.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH v5 0/7] Add script for real-time telemetry monitoring
From: Thomas Monjalon @ 2026-07-12 15:06 UTC (permalink / raw)
To: Bruce Richardson; +Cc: dev
In-Reply-To: <20260505100833.2885047-1-bruce.richardson@intel.com>
> Bruce Richardson (7):
> usertools: add new script to monitor telemetry on terminal
> usertools/telemetry-watcher: add displaying stats
> usertools/telemetry-watcher: add delta and timeout opts
> usertools/telemetry-watcher: add total and one-line opts
> usertools/telemetry-watcher: add thousands separator
> usertools/telemetry-watcher: add eth name shortcuts
> usertools/telemetry-watcher: support reconnection
Applied, thanks.
^ permalink raw reply
* Re: [PATCH v3] tools: AI review handle empty Error sections
From: Thomas Monjalon @ 2026-07-12 15:44 UTC (permalink / raw)
To: Matthew Gee; +Cc: dev, stephen, aconole, lylavoie
In-Reply-To: <20260617174402.2123568-1-mgee@iol.unh.edu>
17/06/2026 19:44, Matthew Gee:
> This patch fixes a bug where review-patch.py would detect and report an
> error or warning only based off of the occurrence of the headers of the
> error and warning sections. This led to consistent false positives as
> often AI reviewers will create the header but put "none" or similar
> filler text within the following body.
>
> This patch updates the code in order to check if the AI review has a
> body with error or warnings to fix and not just filler text. This is
> done by keeping track of whether the for loop parser is within an error
> or warning section; analyzing the first non-whitespace line within the
> section. If the first non-whitespace line matches known filler then the
> section can be ignored. It has been observed that if the AI includes
> filler then there is no actual concern.
>
> These changes were tested against 10+ markdown AI review outputs with
> several variations in formatting and filler text. The changes caught
> error or warning sections with actual concerns and successfully ignored
> sections containing only filler.
>
> Signed-off-by: Matthew Gee <mgee@iol.unh.edu>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH] AGENTS.md: add additional checks for crypto related code
From: Thomas Monjalon @ 2026-07-12 15:49 UTC (permalink / raw)
To: Stephen Hemminger
Cc: dev, konstantin.ananyev, vladimir.medvedkin, Aaron Conole
In-Reply-To: <20260625230536.147975-1-stephen@networkplumber.org>
26/06/2026 01:05, Stephen Hemminger:
> Security related code is a high value target and extra precautions
> should be taken. These are hard to catch with checkpatch alone
> so add additional rules to AGENTS file.
>
> Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH v3] devtools: add Vertex AI to review scripts
From: Thomas Monjalon @ 2026-07-12 16:18 UTC (permalink / raw)
To: David Marchand; +Cc: dev, Stephen Hemminger, Aaron Conole
In-Reply-To: <20260625123237.832480-1-david.marchand@redhat.com>
25/06/2026 14:32, David Marchand:
> Add support for Google Vertex AI authentication as an alternative to
> direct API key authentication. All four providers (Anthropic, Google,
> OpenAI, xAI) can now use Vertex AI with Application Default Credentials.
>
> This requires a python dependency google-auth but it is left as
> optional.
>
> Key features:
> - Auto-detection of authentication method based on environment
> - Manual override via --auth flag (auto, direct, vertex)
> - Automatic model name translation for Vertex format
> - Support for both global and regional Vertex endpoints
> - Proper error handling for Vertex API responses
>
> Provider-specific implementations:
> - Anthropic: Uses /publishers/anthropic/models/{model}:rawPredict
> with model name format claude-sonnet-4-5@20250929
> - Google: Uses /publishers/google/models/{model}:generateContent
> - OpenAI/xAI: Use /endpoints/openapi/chat/completions
> with publisher prefix (e.g., openai/gpt-oss-120b-maas)
>
> Authentication detection logic:
> - Vertex: Requires google-auth library and ADC configured
> - Direct: Falls back to API key from environment variables
>
> Available models on Vertex AI:
> - Anthropic: All Claude models
> - Google: All Gemini models
> - OpenAI: gpt-oss-120b-maas, gpt-oss-20b-maas (open-weight only)
> - xAI: grok-4.20-*, grok-4.1-fast-* variants
>
> Signed-off-by: David Marchand <david.marchand@redhat.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH] checkpatches: suppress warnings about msleep()
From: Thomas Monjalon @ 2026-07-12 16:26 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: dev
In-Reply-To: <20260624162553.79057-1-stephen@networkplumber.org>
24/06/2026 18:25, Stephen Hemminger:
> The DPDK checkpatch uses the underlying kernel tool which
> does some checks that are only relevant in kernel code.
> The warning about msleep() time only makes sense in the
> kernel.
>
> Suppress feedback like:
>
> WARNING:MSLEEP: msleep < 20ms can sleep for up to 20ms; see function description of msleep().
> + msleep(10);
>
> Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH v2] doc, eal, devtools: discourage new __rte_always_inline
From: Thomas Monjalon @ 2026-07-12 19:33 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: dev
In-Reply-To: <20260601172104.311909-1-stephen@networkplumber.org>
01/06/2026 19:21, Stephen Hemminger:
> Modern compilers at -O2 make good inlining decisions for small
> static inline functions; forced inlining via __rte_always_inline
> should be reserved for cases where it is required for correctness
> or for documented measured performance reasons.
>
> Document the policy in the coding style guide and add a
> checkpatches.sh entry that flags when new uses of the attribute
> are introduced. Checkpatches is not an absolute blocker to
> acceptance, only an indicator that more review is needed.
>
> Add additional comments about use of __rte_always_inline,
> __rte_noinline, __rte_hot, and __rte_cold to the rte_common.h
> to aid developers.
>
> Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
Reviewed-by: Morten Brørup <mb@smartsharesystems.com>
Acked-by: Konstantin Ananyev <konstantin.ananyev@huawei.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH] doc: update warnings about primary/secondary process
From: Thomas Monjalon @ 2026-07-12 19:45 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: dev, Anatoly Burakov
In-Reply-To: <20260408152808.201257-1-stephen@networkplumber.org>
08/04/2026 17:28, Stephen Hemminger:
> The existing documentation about primary/secondary requirements
> is not strong enough; make it clear what the requirements are.
> This may be obvious already to developers but not users.
>
> Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
Applied, thanks.
^ permalink raw reply
* RE: DPDK release candidate 26.07-rc2
From: Xu, HailinX @ 2026-07-13 1:51 UTC (permalink / raw)
To: Thomas Monjalon, dev
Cc: Mcnamara, John, Richardson, Bruce, Ferruh Yigit,
Hosamani, Manjunathgouda, Puttaswamy, Rajesh T
In-Reply-To: <CP3kiV_jTf67aEg8Usilhg@monjalon.net>
> -----Original Message-----
> From: Thomas Monjalon <thomas@monjalon.net>
> Sent: Friday, July 3, 2026 10:59 AM
> To: announce@dpdk.org
> Subject: DPDK release candidate 26.07-rc2
>
> A new DPDK release candidate is ready for testing:
> https://git.dpdk.org/dpdk/tag/?id=v26.07-rc2
>
> There are 289 new patches in this snapshot.
>
> Release notes:
> https://doc.dpdk.org/guides/rel_notes/release_26_07.html
>
> There are many fixes and new drivers features.
>
> Please test and report issues on bugs.dpdk.org.
>
> Patches to improve tooling, examples and documentation are welcome.
>
> Thank you everyone
>
Update the test status for Intel part. dpdk26.07-rc2 all validation test done. found 4 new issues.
New issues:
1. [dpdk-26.07] dcf_lifecycle/handle_acl_filter_01: in certain situations, match rule packets are not dropped -> Intel development is investigating
2. [dpdk-26.07rc2]virtio_perf_cryptodev_func/virtio_aes_cbc_sha1_hmac: EAL: Error: Invalid memory -> has fix patch
https://patches.dpdk.org/project/dpdk/patch/20260706095746.2586714-2-radu.nicolau@intel.com/
3. Bug 1964 - [dpdk26.07-rc2] DPDK build failed with EXTRA_CFLAGS='-O1' on Ubuntu26.04 -> Not yet resolved
4. Bug 1963 - hotplug_mp: attach the share device failed in secondary processe -> Fixed
* Build & CFLAG compile: cover the build test with latest GCC/Clang version on the following OS(all passed)
- Ubuntu25.10/Ubuntu26.04
- RHEL9.6/RHEL10
- Fedora43
- FreeBSD15.0
- SUSE16
- OpenAnolis8.10
- OpenEuler24.04-SP2
- AzureLinux3.0
* Function tests: All test done and found 4 issues.
- ICE-(E810, E825, E830, E835, E2100) PF/VF: test scenarios including basic/RTE_FLOW/TSO/Jumboframe/checksum offload/mac_filter/VLAN/VXLAN/RSS/Switch/Package Management/Flow Director/Advanced Tx/Advanced RSS/ACL/DCF/Flexible Descriptor, etc.
- i40E-(XXV710, X722) PF/VF: test scenarios including basic/RTE_FLOW/TSO/Jumboframe/checksum offload/mac_filter/VLAN/VXLAN/RSS, etc.
- IXGBE-(E610, X550) PF/VF: test scenarios including basic/TSO/Jumboframe/checksum offload/mac_filter/VLAN/VXLAN/RSS, etc.
- IGC-(i226) PF: test scenarios including basic/RTE_FLOW/TSO/Jumboframe/checksum offload/mac_filter/VLAN/VXLAN/RSS, etc.
- IPsec: test scenarios including ipsec/ipsec-gw/ipsec library basic test - QAT&SW/FIB library, etc.
- Virtio: both function and performance test are covered. Such as PVP/Virtio_loopback/virtio-user loopback/virtio-net VM2VM perf testing/VMAWARE ESXI 9.0, etc.
- Cryptodev: test scenarios including Cryptodev API testing/CompressDev ISA-L/QAT/ZLIB PMD Testing/FIPS, etc.
- Other: test scenarios including AF_XDP, Power, CBDMA, DSA
* Performance test: All test done and passed
- Thoughput Performance
- Cryptodev Latency
- PF/VF NIC single core
- XXV710/E810/E825/E2100 NIC Performance
Regards,
Xu, Hailin
^ permalink raw reply
* Re: [PATCH v2 0/5] uncore power improvements and auto-detection
From: lihuisong (C) @ 2026-07-13 3:57 UTC (permalink / raw)
To: anatoly.burakov, sivaprasad.tummala
Cc: dev, thomas, stephen, fengchengwen, yangxingui, zhanjie9,
lihuisong
In-Reply-To: <20260526081138.1434947-1-lihuisong@huawei.com>
Kindly ping for review.
On 5/26/2026 4:11 PM, Huisong Li wrote:
> This series improves the uncore power management in l3fwd-power
> and adds automatic detection of uncore drivers in the power library.
>
> - Fix uncore deinitialization for non-legacy modes
> - Enable power QoS for all modes (not just legacy)
> - Fix uncore help text and log messages
> - Relocate uncore initialization from arg parsing to init_power_library()
> - Support automatic probing of multiple uncore drivers in AUTO_DETECT
>
> ---
> v2:
> - Remove the patch which add global uncore init and deinit interface.
> - Remove the last patch in l3fwd-power about these new interface.
> Will send them after this series.
> - v1 link:
> https://inbox.dpdk.org/dev/20260512023513.460169-1-lihuisong@huawei.com/
>
> ---
>
> Huisong Li (5):
> examples/l3fwd-power: fix uncore deinit for non-legacy
> examples/l3fwd-power: enable power QoS for all modes
> examples/l3fwd-power: fix uncore help and log info
> examples/l3fwd-power: relocate uncore initialization
> power: support automatic detection of uncore driver
>
> doc/guides/rel_notes/release_26_07.rst | 6 +
> .../sample_app_ug/l3_forward_power_man.rst | 2 +-
> examples/l3fwd-power/main.c | 256 +++++++++---------
> lib/power/rte_power_uncore.c | 46 +++-
> 4 files changed, 178 insertions(+), 132 deletions(-)
>
^ permalink raw reply
* Re: [PATCH] power/intel_uncore: reduce log level for dependency missing
From: lihuisong (C) @ 2026-07-13 3:57 UTC (permalink / raw)
To: anatoly.burakov, sivaprasad.tummala
Cc: dev, thomas, stephen, fengchengwen, yangxingui, zhanjie9
In-Reply-To: <20260512013047.375535-1-lihuisong@huawei.com>
Kindly ping for review.
On 5/12/2026 9:30 AM, Huisong Li wrote:
> When run dpdk-l3fwd with '-u' on non-X86 platform, user would
> happen a noisy print as the following:
> "POWER: Uncore frequency management not supported/enabled on this
> kernel. Please enable CONFIG_INTEL_UNCORE_FREQ_CONTROL if on Intel
> x86 with linux kernel >= 5.6".
>
> The root cause is that intel_uncore driver's .init() will be called
> on any platform when use automatic detection mode. The function in
> intel_uncore driver will print above log on non-X86 platform.
>
> But the existing uncore core cannot solve this problem unless break
> ABI to add new callback. So reduce its log level to avoid this
> incorrect prompt.
>
> Signed-off-by: Huisong Li <lihuisong@huawei.com>
> ---
> drivers/power/intel_uncore/intel_uncore.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/power/intel_uncore/intel_uncore.c b/drivers/power/intel_uncore/intel_uncore.c
> index 6759ea1445..ebca395075 100644
> --- a/drivers/power/intel_uncore/intel_uncore.c
> +++ b/drivers/power/intel_uncore/intel_uncore.c
> @@ -419,7 +419,7 @@ power_intel_uncore_get_num_pkgs(void)
>
> d = opendir(INTEL_UNCORE_FREQUENCY_DIR);
> if (d == NULL) {
> - POWER_LOG(ERR,
> + POWER_LOG(DEBUG,
> "Uncore frequency management not supported/enabled on this kernel. "
> "Please enable CONFIG_INTEL_UNCORE_FREQ_CONTROL if on Intel x86 with linux kernel"
> " >= 5.6");
> @@ -457,7 +457,7 @@ power_intel_uncore_get_num_dies(unsigned int pkg)
>
> d = opendir(INTEL_UNCORE_FREQUENCY_DIR);
> if (d == NULL) {
> - POWER_LOG(ERR,
> + POWER_LOG(DEBUG,
> "Uncore frequency management not supported/enabled on this kernel. "
> "Please enable CONFIG_INTEL_UNCORE_FREQ_CONTROL if on Intel x86 with linux kernel"
> " >= 5.6");
^ permalink raw reply
* [PATCH] net/mlx5: avoid wildcard drop flow in priority discovery
From: Gavin Hu @ 2026-07-13 4:18 UTC (permalink / raw)
To: dev
Cc: Wei Yan, stable, Dariusz Sosnowski, Viacheslav Ovsiienko,
Bing Zhao, Ori Kam, Suanming Mou, Matan Azrad, Ophir Munk,
Dmitry Kozlyuk
From: Wei Yan <yanwei.wy@bytedance.com>
Priority discovery installs temporary drop flows to probe supported flow
priorities. These flows match a wildcard Ethernet pattern, so they can
also match real traffic while discovery is running. On shared devices this
may temporarily drop kernel traffic and cause TCP connection timeouts.
Constrain the probe flows to match both source and destination MAC
addresses as ff:ff:ff:ff:ff:ff. This keeps the rule valid for discovery
while avoiding matches on normal Ethernet traffic.
Fixes: 3eca5f8a610e ("net/mlx5: move flow priority discovery to Verbs file")
Fixes: c5042f93a425 ("net/mlx5: discover max flow priority using DevX")
Cc: stable@dpdk.org
Signed-off-by: Wei Yan <yanwei.wy@bytedance.com>
Signed-off-by: Gavin Hu <gahu@nvidia.com>
---
drivers/net/mlx5/mlx5_flow_dv.c | 18 ++++++++++++++++++
drivers/net/mlx5/mlx5_flow_verbs.c | 8 ++++++++
2 files changed, 26 insertions(+)
diff --git a/drivers/net/mlx5/mlx5_flow_dv.c b/drivers/net/mlx5/mlx5_flow_dv.c
index 58ebcf87eb..9cb7c59b83 100644
--- a/drivers/net/mlx5/mlx5_flow_dv.c
+++ b/drivers/net/mlx5/mlx5_flow_dv.c
@@ -19794,6 +19794,22 @@ mlx5_flow_discover_dr_action_support(struct rte_eth_dev *dev)
void *matcher = NULL;
void *flow = NULL;
int ret = -1;
+ struct rte_flow_item_eth eth;
+ struct rte_flow_item item = {
+ .type = RTE_FLOW_ITEM_TYPE_ETH,
+ .spec = ð,
+ .mask = ð,
+ };
+
+ memset(ð, 0, sizeof(eth));
+ memset(ð.hdr.dst_addr, 0xff, sizeof(eth.hdr.dst_addr));
+ memset(ð.hdr.src_addr, 0xff, sizeof(eth.hdr.src_addr));
+ flow_dv_translate_item_eth(mask.buf, &item,
+ /* inner */ false, /* group */ 0,
+ MLX5_SET_MATCHER_SW_M);
+ flow_dv_translate_item_eth(value.buf, &item,
+ /* inner */ false, /* group */ 0,
+ MLX5_SET_MATCHER_SW_V);
tbl = mlx5_flow_dv_tbl_resource_get(dev, 0, 0, 0, false, NULL,
0, 0, 0, NULL);
@@ -20683,6 +20699,8 @@ flow_dv_discover_priorities(struct rte_eth_dev *dev,
flow.dv.actions[0] = action;
flow.dv.actions_n = 1;
memset(ð, 0, sizeof(eth));
+ memset(ð.hdr.dst_addr, 0xff, sizeof(eth.hdr.dst_addr));
+ memset(ð.hdr.src_addr, 0xff, sizeof(eth.hdr.src_addr));
flow_dv_translate_item_eth(matcher.mask.buf, &item,
/* inner */ false, /* group */ 0,
MLX5_SET_MATCHER_SW_M);
diff --git a/drivers/net/mlx5/mlx5_flow_verbs.c b/drivers/net/mlx5/mlx5_flow_verbs.c
index bb240d38d9..f92258cb5a 100644
--- a/drivers/net/mlx5/mlx5_flow_verbs.c
+++ b/drivers/net/mlx5/mlx5_flow_verbs.c
@@ -65,6 +65,14 @@ flow_verbs_discover_priorities(struct rte_eth_dev *dev,
.eth = {
.type = IBV_FLOW_SPEC_ETH,
.size = sizeof(struct ibv_flow_spec_eth),
+ .val = {
+ .dst_mac = "\xff\xff\xff\xff\xff\xff",
+ .src_mac = "\xff\xff\xff\xff\xff\xff",
+ },
+ .mask = {
+ .dst_mac = "\xff\xff\xff\xff\xff\xff",
+ .src_mac = "\xff\xff\xff\xff\xff\xff",
+ },
},
.drop = {
.size = sizeof(struct ibv_flow_spec_action_drop),
--
2.27.0
^ permalink raw reply related
* Re: DPDK release candidate 26.07-rc2
From: P, Johnathen @ 2026-07-13 7:01 UTC (permalink / raw)
To: dev@dpdk.org; +Cc: thomas@monjalon.net
AMD General
Please find the AMD platform validation report for DPDK v26.07rc2.
* Summary:
DPDK v26.07rc2 AMD platform validation is complete. Test scenarios were executed across 6 workloads on 5 AMD EPYC platforms using a Mellanox CX7 2×200G NIC. 6 of 6 workloads (TestPMD, L3FWD, Crypto, Compression, LPM Perf, MemCpy) passed.
* Issues:- None
* System Tested:
Processor: EPYC 8635P (84C) | EPYC 9745 (128C) | EPYC 9755 (128C)| EPYC 9654 (96C) | EPYC 8534P (64C) |
Frequency: 1.6 GHz | 2.4 GHz | 2.7 GHz| 2.4 / 3.7 GHz| 2.3 GHz|
Socket: 1| 2| 1| 1| 1|
Cores/Socket: 84| 128| 128| 96| 64|
L3 Cache : 384 MB| 512 MiB| 512 MiB| 384 MiB| 128 MiB|
Memory: 1.5 TiB| 1.5 TiB| 1.5 TiB| 377 GiB| 377 GiB|
DIMM Speed (Configured): 5200 MT/s| 6000 MT/s| 4000 MT/s| 4800 MT/s| 4000 MT/s|
BIOS: RSST100AB| RVOT1006C| RPUT100AA| RTI100DB| RSS100HB|
NPS: 1
SMT: ON
Turbo Boost: OFF| OFF| OFF| OFF| ON |
NIC : CX7 2×200G
NIC Firmware: 24.10-4.1.4| 24.10-4.1.4| 28.43.2566| 28.43.2566| 28.43.2566|
MLX Driver: mlx5_core
* Build & Compile:
- OS: Ubuntu 24.04 LTS
- Kernel: 6.8.0-107-generic
- Compiler: GCC 14.2
- Flags: -Dc_args="-march=znver5 -Ofast"
- Build: All 5 AMD EPYC platforms — PASS
* Function Test Cases: Following tests were performed and all passed.
TestPMD: Packet I/O throughput; 1C1T, 1C2T, 8C16T, 16C32T; 64B & 1518B frames; bidirectional; CX7 2×200G
L3FWD: Layer-3 forwarding with LPM routing table; 1C1T, 1C2T, 8C16T, 16C32T; 64B & 1518B frames
Crypto: rte_cryptodev AES validation; AES-CBC-128/256, AES-GCM-128/256; 64B–4096B buffers; 13 of 23 algorithms validated.
Compression: rte_compressdev validation using zlib & ISA-L; Levels 1/6/9; 4KB–128KB buffers
LPM Perf: rte_lpm microbenchmark; Add/Delete/Lookup; cycles/op; 1C1T & 2C1T
MemCpy: rte_memcpy benchmark; aligned & unaligned; constant & variable copy; get/set cycles/op
* Performance Test:
TestPMD-IO — PASS
Peak 267.00 Mpps @ 64B (Genoa, 16C32T, CX7 2×200G).
All 32 scenarios passed.
L3FWD — PASS
Peak 266.00 Mpps @ 64B (Siena, 16C32T).
All 32 scenarios passed.
Crypto — PASS
AES-CBC/GCM validation across 4 platforms and 7 packet sizes (64B–4096B).
All 112 scenarios passed. SNOW3G/ZUC (10 algorithms) not supported — see Issue #2.
Compression — PASS
Zlib & ISA-L validation across all 5 platforms at Levels 1/6/9.
All 180 scenarios passed.
LPM Perf — PASS
Add/Delete/Lookup microbenchmark validation across all 5 platforms.
All 15 scenarios passed.
MemCpy — PASS
Aligned and unaligned memcpy benchmark validation across 4 platforms.
All 14 scenarios passed.
Thanks & Regards,
Johnathen.P
^ permalink raw reply
* [PATCH v6 0/2] Intel network driver enhancements
From: Dawid Wesierski @ 2026-07-13 9:42 UTC (permalink / raw)
To: dev; +Cc: thomas, stephen, bruce.richardson, marek.kasiewicz,
Dawid Wesierski
In-Reply-To: <20260708231926.1550698-1-dawid.wesierski@intel.com>
This series contains enhancements for Intel ice and iavf drivers.
v6:
- doc/ice: addressed Bruce's review comments. Dropped re-wrapping of
existing text to follow DPDK policy (starting each sentence on a new line).
- doc/ice: explicitly noted that invalid rl_burst_size values cause the
driver to fail to initialize (hard failure).
- net/iavf: re-submitted patch 2 (runtime queue setup race fix) which
had application issues in v5.
v5:
- Added documented rejection of invalid values to rl_burst_size.
- Improved commit message for iavf runtime queue setup fix.
Dawid Wesierski (2):
doc: fix ice scheduler rate-limiter burst size description
net/iavf: disable runtime queue setup during queue rate limiting
doc/guides/nics/ice.rst | 1 +
doc/guides/nics/intel_vf.rst | 10 ++++++++++
doc/guides/rel_notes/release_26_07.rst | 3 +++
drivers/net/intel/iavf/iavf_ethdev.c | 23 ++++++++++++++++++++---
drivers/net/intel/iavf/iavf_tm.c | 2 ++
5 files changed, 36 insertions(+), 3 deletions(-)
--
2.47.3
---------------------------------------------------------------------
Intel Technology Poland sp. z o.o.
ul. Slowackiego 173 | 80-298 Gdansk | Sad Rejonowy Gdansk Polnoc | VII Wydzial Gospodarczy Krajowego Rejestru Sadowego - KRS 101882 | NIP 957-07-52-316 | Kapital zakladowy 200.000 PLN.
Spolka oswiadcza, ze posiada status duzego przedsiebiorcy w rozumieniu ustawy z dnia 8 marca 2013 r. o przeciwdzialaniu nadmiernym opoznieniom w transakcjach handlowych.
Ta wiadomosc wraz z zalacznikami jest przeznaczona dla okreslonego adresata i moze zawierac informacje poufne. W razie przypadkowego otrzymania tej wiadomosci, prosimy o powiadomienie nadawcy oraz trwale jej usuniecie; jakiekolwiek przegladanie lub rozpowszechnianie jest zabronione.
This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). If you are not the intended recipient, please contact the sender and delete all copies; any review or distribution by others is strictly prohibited.
^ permalink raw reply
* [PATCH v6 1/2] doc: fix ice scheduler rate-limiter burst size description
From: Dawid Wesierski @ 2026-07-13 9:42 UTC (permalink / raw)
To: dev
Cc: thomas, stephen, bruce.richardson, marek.kasiewicz,
Dawid Wesierski, Anatoly Burakov
In-Reply-To: <20260713094240.1721105-1-dawid.wesierski@intel.com>
The paragraph describing the rl_burst_size devarg did not mention
that out-of-range values are rejected, which can otherwise look like
a silent no-op to a reader. Add a note that such values cause the
driver to fail to initialize, since ice_cfg_rl_burst_size() validates
the value and dev_probe() bails out with -EINVAL if it is rejected.
Fixes: b3f2afb3b7ea ("net/ice: add scheduler rate-limiter burst size devarg")
Signed-off-by: Dawid Wesierski <dawid.wesierski@intel.com>
---
doc/guides/nics/ice.rst | 1 +
1 file changed, 1 insertion(+)
diff --git a/doc/guides/nics/ice.rst b/doc/guides/nics/ice.rst
index 5589ce934f..2f7c9e6f7c 100644
--- a/doc/guides/nics/ice.rst
+++ b/doc/guides/nics/ice.rst
@@ -164,6 +164,7 @@ Runtime Configuration
Time-sensitive applications can lower this value to reduce Tx latency jitter
at the cost of throughput by setting the ``rl_burst_size`` devargs parameter, in bytes.
A value of ``0`` (the default) keeps the hardware default.
+ Values outside the range supported by the hardware cause the driver to fail to initialize.
For example::
--
2.47.3
---------------------------------------------------------------------
Intel Technology Poland sp. z o.o.
ul. Slowackiego 173 | 80-298 Gdansk | Sad Rejonowy Gdansk Polnoc | VII Wydzial Gospodarczy Krajowego Rejestru Sadowego - KRS 101882 | NIP 957-07-52-316 | Kapital zakladowy 200.000 PLN.
Spolka oswiadcza, ze posiada status duzego przedsiebiorcy w rozumieniu ustawy z dnia 8 marca 2013 r. o przeciwdzialaniu nadmiernym opoznieniom w transakcjach handlowych.
Ta wiadomosc wraz z zalacznikami jest przeznaczona dla okreslonego adresata i moze zawierac informacje poufne. W razie przypadkowego otrzymania tej wiadomosci, prosimy o powiadomienie nadawcy oraz trwale jej usuniecie; jakiekolwiek przegladanie lub rozpowszechnianie jest zabronione.
This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). If you are not the intended recipient, please contact the sender and delete all copies; any review or distribution by others is strictly prohibited.
^ permalink raw reply related
* [PATCH v6 2/2] net/iavf: disable runtime queue setup during queue rate limiting
From: Dawid Wesierski @ 2026-07-13 9:42 UTC (permalink / raw)
To: dev
Cc: thomas, stephen, bruce.richardson, marek.kasiewicz,
Dawid Wesierski, Anatoly Burakov, Vladimir Medvedkin
In-Reply-To: <20260713094240.1721105-1-dawid.wesierski@intel.com>
Runtime queue setup on E810 VFs causes queue state corruption when
queues are dynamically reconfigured while the hardware rate limiter
is actively pacing TX queues. Queue configuration messages to the PF
via virtchnl can race with ongoing TX operations, leading to undefined
behavior.
Rather than gating this behind a devarg that an application would have
to know to set (and could just as easily avoid triggering the race by
not calling rte_eth_{rx,tx}_queue_setup() on a running port), stop
advertising RTE_ETH_DEV_CAPA_RUNTIME_RX_QUEUE_SETUP and
RTE_ETH_DEV_CAPA_RUNTIME_TX_QUEUE_SETUP as soon as the application
commits a per-queue bandwidth rte_tm hierarchy, i.e. as soon as the
condition that causes the race actually exists. iavf_dev_info_get() is
re-queried by the ethdev layer on every rx/tx_queue_setup() call, so
this is enough for the generic layer to start rejecting runtime queue
(re)configuration with -EBUSY once queue rate limiting is active, and
to automatically allow it again once the rte_tm hierarchy is torn
down.
vf->qtc_map, already used elsewhere to look up a queue's TC mapping,
is repurposed as the "queue bandwidth committed" signal since it's set
by iavf_hierarchy_commit() exactly when a per-queue bandwidth mapping
has been pushed to the PF, regardless of whether the port was stopped
at the time. Fix two related issues found while making it load-bearing
for this check:
- iavf_hierarchy_commit() replaced vf->qtc_map on every successful
commit without freeing the previous allocation, leaking memory.
- vf->qtc_map was never released on VF teardown, so
iavf_uninit_vf()/iavf_init_vf() (e.g. across a VF reset) could leave
a stale pointer referencing freed unrelated memory, and the runtime
queue setup capability would never be re-advertised after a reset.
Both are fixed by freeing vf->qtc_map before replacing it in
iavf_hierarchy_commit(), and freeing and clearing it in
iavf_uninit_vf().
Signed-off-by: Marek Kasiewicz <marek.kasiewicz@intel.com>
Signed-off-by: Dawid Wesierski <dawid.wesierski@intel.com>
---
doc/guides/nics/intel_vf.rst | 10 ++++++++++
doc/guides/rel_notes/release_26_07.rst | 3 +++
drivers/net/intel/iavf/iavf_ethdev.c | 23 ++++++++++++++++++++---
drivers/net/intel/iavf/iavf_tm.c | 2 ++
4 files changed, 35 insertions(+), 3 deletions(-)
diff --git a/doc/guides/nics/intel_vf.rst b/doc/guides/nics/intel_vf.rst
index e010f852cf..a47e3f6736 100644
--- a/doc/guides/nics/intel_vf.rst
+++ b/doc/guides/nics/intel_vf.rst
@@ -150,6 +150,16 @@ Intel\ |reg| E800 Series Ethernet devices:
for example: ``-a 18:00.0,quanta_size=2048``.
The default value is 1024, and quanta size should be set as the product of 64 in legacy host interface mode.
+* Runtime (post-start) Rx/Tx queue setup can race with the hardware Tx rate
+ limiter on E810 VFs and corrupt queue state.
+ Once an application commits a per-queue bandwidth ``rte_tm`` hierarchy,
+ the driver automatically stops advertising
+ ``RTE_ETH_DEV_CAPA_RUNTIME_RX_QUEUE_SETUP`` and
+ ``RTE_ETH_DEV_CAPA_RUNTIME_TX_QUEUE_SETUP``,
+ so ``rte_eth_rx_queue_setup()``/``rte_eth_tx_queue_setup()``
+ are rejected with ``-EBUSY`` on a running port for as long as queue rate
+ limiting is active.
+
* When using the Intel out-of-tree "ice" PF/kernel driver v1.13.7 or later,
to create VFs with >16 queues (aka. "large VFs"),
it is necessary to change the rss_lut_vf_addr setting in sysfs from the default of 64 to 512.
diff --git a/doc/guides/rel_notes/release_26_07.rst b/doc/guides/rel_notes/release_26_07.rst
index 6badd6d91b..4faa7b8fe2 100644
--- a/doc/guides/rel_notes/release_26_07.rst
+++ b/doc/guides/rel_notes/release_26_07.rst
@@ -144,6 +144,9 @@ New Features
* Added support for QinQ offloading operations.
* Added support for transmitting LLDP packets based on mbuf packet type.
* Implemented AVX2 context descriptor transmit paths.
+ * Runtime Rx/Tx queue setup is now automatically disabled while a
+ per-queue bandwidth ``rte_tm`` hierarchy is committed, to avoid
+ corrupting queue state on E810 VFs.
* **Updated Intel ice driver.**
diff --git a/drivers/net/intel/iavf/iavf_ethdev.c b/drivers/net/intel/iavf/iavf_ethdev.c
index d601ec3b6a..e475b64971 100644
--- a/drivers/net/intel/iavf/iavf_ethdev.c
+++ b/drivers/net/intel/iavf/iavf_ethdev.c
@@ -1160,9 +1160,18 @@ iavf_dev_info_get(struct rte_eth_dev *dev, struct rte_eth_dev_info *dev_info)
dev_info->reta_size = vf->vf_res->rss_lut_size;
dev_info->flow_type_rss_offloads = IAVF_RSS_OFFLOAD_ALL;
dev_info->max_mac_addrs = IAVF_NUM_MACADDR_MAX;
- dev_info->dev_capa =
- RTE_ETH_DEV_CAPA_RUNTIME_RX_QUEUE_SETUP |
- RTE_ETH_DEV_CAPA_RUNTIME_TX_QUEUE_SETUP;
+ /*
+ * Runtime queue setup can race with the hardware Tx rate limiter on
+ * E810 VFs and corrupt queue state. Once a per-queue bandwidth rte_tm
+ * hierarchy has been committed (vf->qtc_map is set), stop advertising
+ * the capability so the ethdev layer rejects further rx/tx_queue_setup()
+ * calls on a running port with -EBUSY. The capability is re-advertised
+ * automatically once the rte_tm hierarchy is torn down.
+ */
+ if (vf->qtc_map == NULL)
+ dev_info->dev_capa =
+ RTE_ETH_DEV_CAPA_RUNTIME_RX_QUEUE_SETUP |
+ RTE_ETH_DEV_CAPA_RUNTIME_TX_QUEUE_SETUP;
dev_info->rx_offload_capa =
RTE_ETH_RX_OFFLOAD_VLAN_STRIP |
RTE_ETH_RX_OFFLOAD_QINQ_STRIP |
@@ -2760,6 +2769,14 @@ iavf_uninit_vf(struct rte_eth_dev *dev)
rte_free(vf->proto_xtr);
vf->proto_xtr = NULL;
+ /*
+ * Drop the committed queue/TC bandwidth mapping so a subsequent
+ * iavf_init_vf() (e.g. after a device reset) starts with runtime
+ * Rx/Tx queue setup available again (see iavf_dev_info_get()).
+ */
+ rte_free(vf->qtc_map);
+ vf->qtc_map = NULL;
+
rte_free(vf->rss_lut);
vf->rss_lut = NULL;
rte_free(vf->rss_key);
diff --git a/drivers/net/intel/iavf/iavf_tm.c b/drivers/net/intel/iavf/iavf_tm.c
index faa2d4b8a0..fc84bf7e6b 100644
--- a/drivers/net/intel/iavf/iavf_tm.c
+++ b/drivers/net/intel/iavf/iavf_tm.c
@@ -912,6 +912,8 @@ static int iavf_hierarchy_commit(struct rte_eth_dev *dev,
if (ret_val)
goto fail_clear;
+ /* replace the previously committed mapping, if any */
+ rte_free(vf->qtc_map);
vf->qtc_map = qtc_map;
free(old_qtc_map);
if (adapter->stopped == 1)
--
2.47.3
---------------------------------------------------------------------
Intel Technology Poland sp. z o.o.
ul. Slowackiego 173 | 80-298 Gdansk | Sad Rejonowy Gdansk Polnoc | VII Wydzial Gospodarczy Krajowego Rejestru Sadowego - KRS 101882 | NIP 957-07-52-316 | Kapital zakladowy 200.000 PLN.
Spolka oswiadcza, ze posiada status duzego przedsiebiorcy w rozumieniu ustawy z dnia 8 marca 2013 r. o przeciwdzialaniu nadmiernym opoznieniom w transakcjach handlowych.
Ta wiadomosc wraz z zalacznikami jest przeznaczona dla okreslonego adresata i moze zawierac informacje poufne. W razie przypadkowego otrzymania tej wiadomosci, prosimy o powiadomienie nadawcy oraz trwale jej usuniecie; jakiekolwiek przegladanie lub rozpowszechnianie jest zabronione.
This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). If you are not the intended recipient, please contact the sender and delete all copies; any review or distribution by others is strictly prohibited.
^ permalink raw reply related
* [PATCH v6 0/2] Intel network driver enhancements
From: Dawid Wesierski @ 2026-07-13 9:42 UTC (permalink / raw)
To: dev; +Cc: thomas, stephen, bruce.richardson, marek.kasiewicz,
Dawid Wesierski
In-Reply-To: <20260708231926.1550698-1-dawid.wesierski@intel.com>
This series contains enhancements for Intel ice and iavf drivers.
v6:
- doc/ice: addressed Bruce's review comments. Dropped re-wrapping of
existing text to follow DPDK policy (starting each sentence on a new line).
- doc/ice: explicitly noted that invalid rl_burst_size values cause the
driver to fail to initialize (hard failure).
- net/iavf: re-submitted patch 2 (runtime queue setup race fix) which
had application issues in v5.
v5:
- Added documented rejection of invalid values to rl_burst_size.
- Improved commit message for iavf runtime queue setup fix.
Dawid Wesierski (2):
doc: fix ice scheduler rate-limiter burst size description
net/iavf: disable runtime queue setup during queue rate limiting
doc/guides/nics/ice.rst | 1 +
doc/guides/nics/intel_vf.rst | 10 ++++++++++
doc/guides/rel_notes/release_26_07.rst | 3 +++
drivers/net/intel/iavf/iavf_ethdev.c | 23 ++++++++++++++++++++---
drivers/net/intel/iavf/iavf_tm.c | 2 ++
5 files changed, 36 insertions(+), 3 deletions(-)
--
2.47.3
---------------------------------------------------------------------
Intel Technology Poland sp. z o.o.
ul. Slowackiego 173 | 80-298 Gdansk | Sad Rejonowy Gdansk Polnoc | VII Wydzial Gospodarczy Krajowego Rejestru Sadowego - KRS 101882 | NIP 957-07-52-316 | Kapital zakladowy 200.000 PLN.
Spolka oswiadcza, ze posiada status duzego przedsiebiorcy w rozumieniu ustawy z dnia 8 marca 2013 r. o przeciwdzialaniu nadmiernym opoznieniom w transakcjach handlowych.
Ta wiadomosc wraz z zalacznikami jest przeznaczona dla okreslonego adresata i moze zawierac informacje poufne. W razie przypadkowego otrzymania tej wiadomosci, prosimy o powiadomienie nadawcy oraz trwale jej usuniecie; jakiekolwiek przegladanie lub rozpowszechnianie jest zabronione.
This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). If you are not the intended recipient, please contact the sender and delete all copies; any review or distribution by others is strictly prohibited.
^ permalink raw reply
* [PATCH v6 1/2] doc: fix ice scheduler rate-limiter burst size description
From: Dawid Wesierski @ 2026-07-13 9:42 UTC (permalink / raw)
To: dev
Cc: thomas, stephen, bruce.richardson, marek.kasiewicz,
Dawid Wesierski, Anatoly Burakov
In-Reply-To: <20260713094259.1721234-1-dawid.wesierski@intel.com>
The paragraph describing the rl_burst_size devarg did not mention
that out-of-range values are rejected, which can otherwise look like
a silent no-op to a reader. Add a note that such values cause the
driver to fail to initialize, since ice_cfg_rl_burst_size() validates
the value and dev_probe() bails out with -EINVAL if it is rejected.
Fixes: b3f2afb3b7ea ("net/ice: add scheduler rate-limiter burst size devarg")
Signed-off-by: Dawid Wesierski <dawid.wesierski@intel.com>
---
doc/guides/nics/ice.rst | 1 +
1 file changed, 1 insertion(+)
diff --git a/doc/guides/nics/ice.rst b/doc/guides/nics/ice.rst
index 5589ce934f..2f7c9e6f7c 100644
--- a/doc/guides/nics/ice.rst
+++ b/doc/guides/nics/ice.rst
@@ -164,6 +164,7 @@ Runtime Configuration
Time-sensitive applications can lower this value to reduce Tx latency jitter
at the cost of throughput by setting the ``rl_burst_size`` devargs parameter, in bytes.
A value of ``0`` (the default) keeps the hardware default.
+ Values outside the range supported by the hardware cause the driver to fail to initialize.
For example::
--
2.47.3
---------------------------------------------------------------------
Intel Technology Poland sp. z o.o.
ul. Slowackiego 173 | 80-298 Gdansk | Sad Rejonowy Gdansk Polnoc | VII Wydzial Gospodarczy Krajowego Rejestru Sadowego - KRS 101882 | NIP 957-07-52-316 | Kapital zakladowy 200.000 PLN.
Spolka oswiadcza, ze posiada status duzego przedsiebiorcy w rozumieniu ustawy z dnia 8 marca 2013 r. o przeciwdzialaniu nadmiernym opoznieniom w transakcjach handlowych.
Ta wiadomosc wraz z zalacznikami jest przeznaczona dla okreslonego adresata i moze zawierac informacje poufne. W razie przypadkowego otrzymania tej wiadomosci, prosimy o powiadomienie nadawcy oraz trwale jej usuniecie; jakiekolwiek przegladanie lub rozpowszechnianie jest zabronione.
This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). If you are not the intended recipient, please contact the sender and delete all copies; any review or distribution by others is strictly prohibited.
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox