[PWCI] "Fixes for Fedora Rawhide"

[ovsrobot]

Auto-submission for "http://patchwork.dpdk.org/project/dpdk/list/?series=36807"

Summary by CodeRabbit

Release Notes

• New Features

  • Added automatic lcore-id remapping option.
  • Added 800G speed support.
  • Added dynamic history field in mbuf (disabled by default).
  • Added Pollara 400 single-port 400G AI NIC support.
  • Added VLAN offload configuration support.
  • Added configurable RX/TX burst sizing options for l3fwd and l3fwd-power applications.

• Bug Fixes

  • Fixed tunnel-aware L4 protocol extraction.
  • Fixed parameter validation in IP reassembly example.

• Documentation

  • Updated platform support and NIC guidance for latest versions.
  • Updated release notes with comprehensive tested platforms section.
  • Added raw pattern documentation for Intel ice NICs.
  • Updated FreeBSD and Windows build instructions.

• Chores

  • Version updated to 25.11.0-rc4.

_{✏️ Tip: You can customize this high-level summary in your review settings.}

[sourcery-ai]

Sorry @ovsrobot, you have reached your weekly rate limit of 500000 diff characters.

Please try again later or upgrade to continue using Sourcery

[coderabbitai]

Walkthrough

This PR includes version bump to 25.11.0-rc4, maintainer scope expansion, const-correctness improvements across multiple drivers, MLX5/TXGBE hardware feature updates, delta-based statistics implementation in NBL driver, burst size configurability in l3fwd example, and extensive documentation updates for release notes and platform guides.

Changes

Cohort / File(s)	Summary
Version & Maintenance MAINTAINERS, VERSION	Updated version to 25.11.0-rc4; added app/test/bpf/ to BPF maintainer scope.
Const-Correctness Type Fixes app/proc-info/main.c, drivers/bus/fslmc/fslmc_bus.c, drivers/bus/ifpga/ifpga_bus.c, drivers/bus/uacce/uacce.c, drivers/common/qat/qat_device.c, drivers/common/qat/qat_device.h, drivers/compress/qat/qat_comp_pmd.c, drivers/crypto/qat/qat_asym.c, drivers/crypto/qat/qat_sym.c, drivers/net/memif/rte_eth_memif.c	Updated local pointers and function return types from char\* to const char\* for read-only usage across multiple drivers and utilities.
MLX5 Hardware Updates drivers/common/mlx5/mlx5_devx_cmds.c, drivers/common/mlx5/mlx5_devx_cmds.h, drivers/common/mlx5/mlx5_prm.h, drivers/net/mlx5/mlx5.c, drivers/net/mlx5/mlx5_flow_flex.c	Added header length field offset mode support to FLEX parser; added workaround flag to capabilities; removed sw_owner v2 fields from capability structure; added conditional gating on offset handling based on WA mode; simplified device capability detection and DV flow enablement logic.
TXGBE Hardware Driver Updates drivers/net/txgbe/base/txgbe_aml.c, drivers/net/txgbe/base/txgbe_aml40.c, drivers/net/txgbe/base/txgbe_eeprom.c, drivers/net/txgbe/base/txgbe_hw.c, drivers/net/txgbe/base/txgbe_mng.c, drivers/net/txgbe/base/txgbe_mng.h, drivers/net/txgbe/base/txgbe_type.h, drivers/net/txgbe/txgbe_rxtx.c	Added host interface command function pointers and SP/AML variants; centralized FW command path through mailbox interface; removed redundant SWMBX semaphore flag from EEPROM operations; assigned dummy TX prepare callback for simple TX path.
NBL Driver Enhancements drivers/net/nbl/nbl_dev/nbl_dev.c, drivers/net/nbl/nbl_dev/nbl_dev.h, drivers/net/nbl/nbl_ethdev.c, drivers/net/nbl/nbl_hw/nbl_resource.h, drivers/net/nbl/nbl_hw/nbl_txrx.c	Added VLAN offload set callback (no-op); introduced reset statistics fields to ring structures; implemented delta-based statistics accounting by storing and subtracting reset snapshots.
CNxK Event Driver Updates drivers/event/cnxk/cn10k_eventdev.c, drivers/event/cnxk/cn10k_worker.h, drivers/event/cnxk/cn20k_eventdev.c, drivers/event/cnxk/cn20k_worker.h	Replaced hardcoded RX offload masks with per-device dev->rx_offloads; initialized local variables (meta_aura, laddr, lmt_id, d_off, cq_w5) to prevent undefined state.
RX Vector Path Initialization drivers/net/cnxk/cn10k_rx.h, drivers/net/cnxk/cn20k_rx.h	Explicitly initialized pointers and offsets (inb_priv, lmt_id, d_off, lbase, laddr, buf_sz, cq_w5) in RX vector processing paths.
TX Prepare Callback Updates drivers/net/hns3/hns3_rxtx.c, drivers/net/ngbe/ngbe_rxtx.c	Changed TX packet prepare callback from NULL to rte_eth_tx_pkt_prepare_dummy for simple TX paths, ensuring non-NULL function pointers.
Other Driver Fixes drivers/net/intel/iavf/iavf_ethdev.c, drivers/net/ntnic/ntnic_ethdev.c, drivers/net/softnic/rte_eth_softnic.c, drivers/crypto/caam_jr/caam_jr_uio.c, drivers/net/enetfec/enet_uio.c	Relaxed RX timestamp offload condition to check only VIRTCHNL_VF_CAP_PTP; removed explicit NULL assignments for tx_pkt_prepare; simplified file_name_match_extract logic.
L3FWD Example Burst Configuration examples/l3fwd/l3fwd.h, examples/l3fwd/l3fwd_common.h, examples/l3fwd/l3fwd_acl.c, examples/l3fwd/l3fwd_em.c, examples/l3fwd/l3fwd_fib.c, examples/l3fwd/l3fwd_lpm.c, examples/l3fwd/main.c	Replaced global nb_pkt_per_burst with separate rx_burst_size and tx_burst_size; added --rx-burst, --tx-burst, --eth-link-speed command-line options; updated burst parsing logic to support per-burst-type configuration and PMD defaults for RX.
Example App Updates examples/ip_reassembly/main.c, examples/l3fwd-power/main.c, examples/server_node_efd/efd_server/main.c, examples/server_node_efd/shared/common.h, examples/vdpa/main.c	Added lcore/queue bounds validation in setup_queue_tbl; added eth-link-speed option to l3fwd-power; updated MAC address buffer sizing to use RTE_ETHER_ADDR_FMT_SIZE; updated RX queue name buffer to use RTE_RING_NAMESIZE; refined iface buffer sizing.
Test & Build Updates app/proc-info/main.c (const), app/test-pmd/csumonly.c, app/test/test_debug.c, doc/api/meson.build, examples/meson.build	Added tunnel-aware L4 protocol parsing via in_tunnel parameter; extended test argument array for PPC64-specific iova-mode option; added install_tag: 'doc' to Meson custom targets; removed conditional -Wformat-truncation warning suppression.
Documentation: Crypto & NIC Guides doc/guides/cryptodevs/ionic.rst, doc/guides/nics/ionic.rst, doc/guides/nics/i40e.rst, doc/guides/nics/ice.rst, doc/guides/nics/mlx5.rst	Updated ionic copyright and added Pollara 400 AI NIC model; updated i40e/ice compatibility tables for version 25.11; expanded mlx5 documentation with synchronous API constraints, default DV flow configuration, and rte_flow_configure prerequisites.
Documentation: Platform & Build Guides doc/guides/linux_gsg/amd_platform.rst, doc/guides/freebsd_gsg/build_dpdk.rst, doc/guides/windows_gsg/build_dpdk.rst, doc/guides/meson.build	Updated AMD platform guide with TURIN support, uncore power functions, and Solarflare NIC guidance; upgraded FreeBSD py38 to py311 pyelftools; updated Windows Visual Studio guidance and LLVM links; added doc install_tag to meson targets.
Documentation: Release Notes & Examples doc/guides/rel_notes/release_25_11.rst, doc/guides/sample_app_ug/l3_forward.rst	Replaced boilerplate with actual feature content; added comprehensive Tested Platforms section; converted Known Issues to platform-specific entries; added --rx-burst and --tx-burst option documentation.

Estimated code review effort

🎯 4 (Complex) | ⏱️ ~60 minutes

Areas requiring extra attention:

• drivers/net/nbl/nbl_hw/nbl_txrx.c — Delta-based statistics implementation requires careful verification of reset snapshot logic and counter arithmetic across all paths (rx/tx, per-queue/total)
• drivers/net/mlx5/ — Hardware capability structure changes and workaround flag conditional logic; verify all callers of mlx5_devx_cmd functions respect new WA mode behavior
• drivers/net/txgbe/base/txgbe_mng.c — Centralized mailbox interface refactoring; ensure all FW command paths correctly route through hw->mbx.host_interface_command
• examples/l3fwd/main.c — Burst size parsing refactor; verify rx_burst_size defaults to PMD-provided value and tx_burst_size respects user input across all loopback modes
• app/test-pmd/csumonly.c — Tunnel-aware L4 parsing logic; verify align_ptype computation handles IPv6 extension types correctly and doesn't break non-tunnel paths

Poem

🐰 A version bump hops along with care,
Burst sizes now flex here and there,
Hardware fields dance through mlx and txgbe's layer,
Stats reset and gather without a prayer,
Const-correctness spreads—what a thrare!

Pre-merge checks and finishing touches

❌ Failed checks (1 warning, 1 inconclusive)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 35.71% which is insufficient. The required threshold is 80.00%.	You can run @coderabbitai generate docstrings to improve docstring coverage.
Title check	❓ Inconclusive	The title '[PWCI] "Fixes for Fedora Rawhide"' is vague and generic. It does not clearly describe the specific changes made in the pull request.	Replace the vague title with a specific, descriptive summary of the main changes. For example: 'Const-correctness improvements and burst size configurability' or a title reflecting the primary change category.

✅ Passed checks (1 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.

✨ Finishing touches

• 📝 Generate docstrings

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment
• Commit unit tests in branch series_36807

Tip

📝 Customizable high-level summaries are now available in beta!

You can now customize how CodeRabbit generates the high-level summary in your pull requests — including its content, structure, tone, and formatting.

• Provide your own instructions using the high_level_summary_instructions setting.
• Format the summary however you like (bullet lists, tables, multi-section layouts, contributor stats, etc.).
• Use high_level_summary_in_walkthrough to move the summary from the description to the walkthrough section.

Example instruction:

"Divide the high-level summary into five sections:

1. 📝 Description — Summarize the main change in 50–60 words, explaining what was done.
2. 📓 References — List relevant issues, discussions, documentation, or related PRs.
3. 📦 Dependencies & Requirements — Mention any new/updated dependencies, environment variable changes, or configuration updates.
4. 📊 Contributor Summary — Include a Markdown table showing contributions:
   | Contributor | Lines Added | Lines Removed | Files Changed |
5. ✔️ Additional Notes — Add any extra reviewer context.
   Keep each section concise (under 200 words) and use bullet or numbered lists for clarity."

Note: This feature is currently in beta for Pro-tier users, and pricing will be announced later.

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

Actionable comments posted: 5

Caution

Some comments are outside the diff and can’t be posted inline due to platform limitations.

⚠️ Outside diff range comments (3)

drivers/net/nbl/nbl_hw/nbl_txrx.c (1)

21-27: Critical bug: Wrong variable checked after rx_rings allocation.

Line 23 checks tx_rings instead of rx_rings. If rx_rings allocation fails, the function will incorrectly return success with a NULL rx_rings pointer, leading to NULL pointer dereference later.

 	txrx_mgt->rx_rings = rte_calloc("nbl_rxrings", rx_num,
 					sizeof(struct nbl_res_rx_ring *), 0);
-	if (!txrx_mgt->tx_rings) {
+	if (!txrx_mgt->rx_rings) {
 		NBL_LOG(ERR, "Allocate the rx rings array failed");
 		rte_free(txrx_mgt->tx_rings);
 		return -ENOMEM;
 	}

drivers/bus/ifpga/ifpga_bus.c (1)

466-507: I'll verify the review comment's concern about potential NULL pointer dereference when c2 is passed to snprintf(). Let me start by examining the codebase.
<function_calls>

shell

Search for all calls to ifpga_parse to understand how it's invoked

rg -n "ifpga_parse" --type=c -A 2 -B 2


</function_calls>

Now let me look at the full context of the ifpga_parse function to understand the control flow:
<function_calls>

shell

Get the full file to see the complete function and any surrounding context

wc -l drivers/bus/ifpga/ifpga_bus.c


</function_calls>

Let me read the full function from the file to carefully trace the logic:
<function_calls>

shell

Read lines 466-510 to see the full function with context

sed -n '466,510p' drivers/bus/ifpga/ifpga_bus.c | cat -n


</function_calls>

Now let me check for any defensive initialization or checks around c2:
<function_calls>

shell

Look at the full function more carefully, including any initialization before line 466

sed -n '460,520p' drivers/bus/ifpga/ifpga_bus.c | cat -n


</function_calls>

Let me search for how ifpga_parse is registered or used as a callback:
<function_calls>

shell

Search for where ifpga_parse is referenced (not just called)

rg -n "ifpga_parse" drivers/bus/ifpga/ -A 1 -B 1


</function_calls>

Let me check if there are any tests or examples that show how the function is expected to be called:
<function_calls>

shell

Search for documentation or test files related to ifpga

find . -path ./build -prune -o -type f ( -name "ifpga" -o -name "test" ) -print | grep -i ifpga | head -20


</function_calls>

Let me look at the entire file context around the function to understand the architecture better:
<function_calls>

shell

See what function this is and what comes before/after

sed -n '450,530p' drivers/bus/ifpga/ifpga_bus.c | cat -n


</function_calls>

Let me check if there's a return statement or check that would prevent execution when c2 is NULL:
<function_calls>

shell

Examine the exact initialization and flow

python3 << 'EOF'

Parse the function carefully

func = """ifpga_parse(const char *name, void *addr)
{
int *out = addr;
struct rte_rawdev *rawdev = NULL;
char rawdev_name[RTE_RAWDEV_NAME_MAX_LEN];
const char *c1 = NULL;
const char *c2 = NULL;
int port = IFPGA_BUS_DEV_PORT_MAX;
char str_port[8];
int str_port_len = 0;
int ret;

memset(str_port, 0, 8);
c1 = strchr(name, '|');
if (c1 != NULL) {
str_port_len = c1 - name;
c2 = c1 + 1;
}

if (str_port_len < 8 &&
str_port_len > 0) {
memcpy(str_port, name, str_port_len);
ret = sscanf(str_port, "%d", &port);
if (ret == -1)
return 0;
}

memset(rawdev_name, 0, sizeof(rawdev_name));
snprintf(rawdev_name, RTE_RAWDEV_NAME_MAX_LEN, "IFPGA:%s", c2);
rawdev = rte_rawdev_pmd_get_named_dev(rawdev_name);

if ((port < IFPGA_BUS_DEV_PORT_MAX) &&
rawdev &&
(addr != NULL))
*out = port;

if ((port < IFPGA_BUS_DEV_PORT_MAX) &&
rawdev)
return 0;
else
return 1;
}"""

Trace the flow:

print("=== Flow Analysis ===")
print("1. c2 is initialized to NULL")
print("2. c1 = strchr(name, '|') - searches for '|' in name")
print("3. If c1 != NULL:")
print(" - str_port_len = c1 - name (distance to separator)")
print(" - c2 = c1 + 1 (pointer to char after '|')")
print("4. If c1 == NULL:")
print(" - c2 remains NULL")
print(" - str_port_len remains 0")
print()
print("5. Later check: if (str_port_len < 8 && str_port_len > 0)")
print(" - This requires str_port_len > 0, which only happens if c1 was found")
print(" - If this check fails, port stays IFPGA_BUS_DEV_PORT_MAX")
print()
print("6. snprintf(rawdev_name, ..., "IFPGA:%s", c2)")
print(" - PROBLEM: c2 can be NULL here!")
print(" - This executes regardless of whether '|' was found")
print()
print("=== Verdict ===")
print("c2 CAN be NULL when reaching snprintf()")
print("If name has no '|', c2 stays NULL → UB in snprintf with %s")
EOF


</function_calls>

Let me check the git history to see if this is a pre-existing issue or introduced by the const change:
<function_calls>

shell

Check git log for recent changes to this function

git log --oneline -10 -- drivers/bus/ifpga/ifpga_bus.c


</function_calls>

<function_calls>

shell

Check the diff for the current PR/branch to see what changed

git show HEAD:drivers/bus/ifpga/ifpga_bus.c | sed -n '460,510p' | cat -n


</function_calls>

Let me see what the PR changed specifically:
<function_calls>

shell

Show the diff for this specific function

git diff HEAD~1 HEAD -- drivers/bus/ifpga/ifpga_bus.c | head -100


</function_calls>

<function_calls>

shell

Try to get current branch info

git log --oneline -3


</function_calls>

<function_calls>

shell

Check if there are uncommitted changes

git status drivers/bus/ifpga/ifpga_bus.c


</function_calls>

<function_calls>

shell

Let's search for how this function is actually used by examining callers more carefully

rg -n ".parse\s*=" drivers/bus/ifpga/ -B 3 -A 3


</function_calls>

<function_calls>

shell

Look at the full file to understand the context better

cat -n drivers/bus/ifpga/ifpga_bus.c | sed -n '1,50p'


</function_calls>

<function_calls>

shell

Look for the structure containing the parse function pointer

rg -n "parse" drivers/bus/ifpga/ifpga_bus.c | head -20


</function_calls>

<function_calls>

shell

Look at the complete context of the function and see what struct it belongs to

sed -n '400,530p' drivers/bus/ifpga/ifpga_bus.c | cat -n


</function_calls>

Let me verify if there's any documentation or contract about the expected input format:
<function_calls>

shell

Look for function documentation or comments

sed -n '450,475p' drivers/bus/ifpga/ifpga_bus.c | cat -n


</function_calls>

<function_calls>

shell

Search for any documentation or comments above the function

sed -n '420,475p' drivers/bus/ifpga/ifpga_bus.c | cat -n


</function_calls>

Based on my verification, I can now provide the rewritten review comment:

c2 remains uninitialized (NULL) if the input name lacks a '|' separator, causing undefined behavior when passed to snprintf() with the %s format specifier.

The const change to c1 and c2 is appropriate for read-only pointer usage. However, the function has a pre-existing NULL-safety issue: c2 is only assigned when strchr(name, '|') succeeds; if the separator is absent, c2 stays NULL yet is unconditionally passed to snprintf(rawdev_name, ..., "IFPGA:%s", c2) at line 493. This is undefined behavior.

Either validate that the name parameter always contains the '|' separator (with a check like if (!c2) return 1;), or provide a safe default like c2 = ""; or c2 = name when no separator exists.

examples/l3fwd/l3fwd_fib.c (1)

184-185: I'll verify the concerns raised in this review comment about potential stack buffer overflow when rx_burst_size exceeds MAX_PKT_BURST. Let me start by examining the file structure and key definitions.
<function_calls>

shell
#!/bin/bash

First, find and examine l3fwd_fib.c

find . -name "l3fwd_fib.c" -type f 2>/dev/null | head -5


</function_calls>

shell
#!/bin/bash

Check the size of l3fwd_fib.c and read relevant sections

wc -l examples/l3fwd/l3fwd_fib.c


</function_calls>
<function_calls>

shell
#!/bin/bash

Read lines around 184-185 and 241-243 to see the actual code

echo "=== Lines 180-195 (first location) ==="
sed -n '180,195p' examples/l3fwd/l3fwd_fib.c
echo ""
echo "=== Lines 237-250 (second location) ==="
sed -n '237,250p' examples/l3fwd/l3fwd_fib.c


</function_calls>
<function_calls>

shell
#!/bin/bash

Search for MAX_PKT_BURST and rx_burst_size definitions

echo "=== Searching for MAX_PKT_BURST ==="
rg -n "MAX_PKT_BURST" examples/l3fwd/
echo ""
echo "=== Searching for rx_burst_size ==="
rg -n "rx_burst_size" examples/l3fwd/


</function_calls>

<function_calls>

shell
#!/bin/bash

Look at l3fwd_common.h for declarations

find . -name "l3fwd_common.h" -type f 2>/dev/null


</function_calls>
<function_calls>

shell
#!/bin/bash

Check l3fwd_common.h for rx_burst_size and MAX_PKT_BURST

if [ -f examples/l3fwd/l3fwd_common.h ]; then
echo "=== l3fwd_common.h content ==="
cat examples/l3fwd/l3fwd_common.h
else

Try to find it

find examples/l3fwd -name "*.h" -type f | xargs ls -la
fi


</function_calls>
<function_calls>

shell
#!/bin/bash

List all header files in l3fwd directory

find examples/l3fwd -name "*.h" -type f


</function_calls>
<function_calls>

shell
#!/bin/bash

Read the full context around line 184 in l3fwd_fib.c

echo "=== Full fib_main_loop function context ==="
sed -n '160,250p' examples/l3fwd/l3fwd_fib.c


</function_calls>

<function_calls>

shell
#!/bin/bash

Search for rte_eth_rx_burst calls in the file

echo "=== RTE_ETH_RX_BURST calls and context ==="
rg -n -B5 -A3 "rte_eth_rx_burst" examples/l3fwd/l3fwd_fib.c


</function_calls>
<function_calls>

shell
#!/bin/bash

Check for MAX_PKT_BURST definition and its value

echo "=== MAX_PKT_BURST definition ==="
rg -n "#define MAX_PKT_BURST" examples/l3fwd/
echo ""

Check the beginning of l3fwd_fib.c for includes and defines

echo "=== First 50 lines of l3fwd_fib.c ==="
head -50 examples/l3fwd/l3fwd_fib.c


</function_calls>
<function_calls>

shell
#!/bin/bash

Search for rx_burst_size declaration and initialization

echo "=== rx_burst_size definition and usage ==="
rg -n -B2 -A5 "rx_burst_size\s*=" examples/l3fwd/


</function_calls>
<function_calls>

shell
#!/bin/bash

Look for validation of rx_burst_size

echo "=== Search for validation/clamping of rx_burst_size ==="
rg -n -B3 -A3 "(rx_burst_size|burst.size)" examples/l3fwd/.c | grep -i -E "(min|max|clamp|>|<|<=|>=)"


</function_calls>
<function_calls>

shell
#!/bin/bash

Get full content around lines 184-185 and also check for function definition

echo "=== Lines 175-200 ==="
sed -n '175,200p' examples/l3fwd/l3fwd_fib.c
echo ""
echo "=== Lines 235-250 ==="
sed -n '235,250p' examples/l3fwd/l3fwd_fib.c


</function_calls>
<function_calls>

shell
#!/bin/bash

Check all files for rx_burst_size declaration and where it comes from

echo "=== All files mentioning rx_burst_size ==="
rg -l "rx_burst_size" examples/l3fwd/
echo ""
echo "=== Full context of rx_burst_size in all files ==="
rg -n -B5 -A5 "rx_burst_size" examples/l3fwd/ 2>/dev/null | head -100


</function_calls>
<function_calls>

shell
#!/bin/bash

Look at the entire l3fwd_common.h to understand the declarations

find examples/l3fwd -type f ( -name ".h" -o -name ".c" ) | xargs grep -l "rx_burst_size" | head -5


</function_calls>
<function_calls>

shell
#!/bin/bash

Examine main l3fwd file

ls -la examples/l3fwd/*.c | head -10


</function_calls>
<function_calls>

shell
#!/bin/bash

Get rx_burst_size from main l3fwd files

echo "=== Searching in all l3fwd C files ==="
for f in examples/l3fwd/*.c; do
if grep -q "rx_burst_size" "$f" 2>/dev/null; then
echo "File: $f"
echo "---"
grep -n -B2 -A5 "rx_burst_size" "$f" 2>/dev/null | head -50
echo ""
fi
done


</function_calls>

<function_calls>

shell
#!/bin/bash

Simpler approach: just read the relevant files directly

echo "=== Content of l3fwd_fib.c lines 1-50 ==="
head -50 examples/l3fwd/l3fwd_fib.c

echo ""
echo "=== Lines 170-260 of l3fwd_fib.c ==="
sed -n '170,260p' examples/l3fwd/l3fwd_fib.c


</function_calls>
<function_calls>

shell
#!/bin/bash

Check for #include statements and MAX_PKT_BURST

echo "=== Includes and early definitions in l3fwd_fib.c ==="
head -100 examples/l3fwd/l3fwd_fib.c | grep -E "#include|#define|MAX_PKT"
echo ""
echo "=== Looking for MAX_PKT_BURST anywhere in l3fwd ==="
grep -r "MAX_PKT_BURST" examples/l3fwd/


</function_calls>
<function_calls>

shell
#!/bin/bash

Let's check git to understand what changed

echo "=== Git status and recent changes ==="
cd examples/l3fwd 2>/dev/null && git log --oneline -10 l3fwd_fib.c 2>/dev/null || echo "Not a git repo or file not tracked"
cd - > /dev/null 2>&1

Let's read the entire l3fwd_fib.c since it's relatively short

wc -l examples/l3fwd/l3fwd_fib.c


</function_calls>
<function_calls>

shell
#!/bin/bash

Read entire file since it's < 300 lines

cat -n examples/l3fwd/l3fwd_fib.c


</function_calls>

<function_calls>

shell
#!/bin/bash

Search for all files that might define MAX_PKT_BURST or rx_burst_size

echo "=== All l3fwd source files ==="
find examples/l3fwd -type f ( -name ".c" -o -name ".h" )

echo ""
echo "=== Grep for MAX_PKT_BURST in entire l3fwd directory ==="
grep -r "MAX_PKT_BURST" examples/l3fwd 2>/dev/null

echo ""
echo "=== Grep for rx_burst_size in entire l3fwd directory ==="
grep -r "rx_burst_size" examples/l3fwd 2>/dev/null


</function_calls>
<function_calls>

shell
#!/bin/bash

Since l3fwd_fib.c is short, let's just output it all

echo "=== COMPLETE l3fwd_fib.c file ==="
cat examples/l3fwd/l3fwd_fib.c


</function_calls>

Let me now search for the related header files and other l3fwd components:
<function_calls>

shell
#!/bin/bash

Check if there's an l3fwd.c or l3fwd_main.c

echo "=== Looking for main l3fwd files ==="
find examples/l3fwd -name ".c" -o -name ".h" | sort

echo ""
echo "=== Searching all l3fwd h files for declarations ==="
for f in examples/l3fwd/*.h; do
if [ -f "$f" ]; then
echo "=== File: $f ==="
cat "$f"
echo ""
fi
done


</function_calls>
<function_calls>

shell
#!/bin/bash

Check for any l3fwd.c or similar main file

echo "=== All C files in l3fwd ==="
find examples/l3fwd -maxdepth 1 -name "*.c" -exec ls -lh {} ;

echo ""

Read the main l3fwd.c if it exists

if [ -f examples/l3fwd/l3fwd.c ]; then
echo "=== l3fwd.c exists, checking for rx_burst_size and MAX_PKT_BURST ==="
grep -n "rx_burst_size|MAX_PKT_BURST" examples/l3fwd/l3fwd.c
fi


</function_calls>

Now let me check if these are defined in any DPDK headers or if they're specific to this example:
<function_calls>

shell
#!/bin/bash

Search the entire repository for these symbols

echo "=== Searching entire repo for MAX_PKT_BURST ==="
grep -r "MAX_PKT_BURST" . 2>/dev/null | grep -v ".git" | head -20

echo ""
echo "=== Searching entire repo for rx_burst_size ==="
grep -r "rx_burst_size" . 2>/dev/null | grep -v ".git" | head -20


</function_calls>

<function_calls>

shell
#!/bin/bash

More targeted search - look in examples directory

echo "=== All l3fwd files ==="
find examples/l3fwd -type f | sort

echo ""
echo "=== Check if l3fwd.c exists and search it ==="
if [ -f "examples/l3fwd/l3fwd.c" ]; then
echo "File exists"
wc -l examples/l3fwd/l3fwd.c
echo "Searching for MAX_PKT_BURST:"
grep -n "MAX_PKT_BURST" examples/l3fwd/l3fwd.c | head
else
echo "examples/l3fwd/l3fwd.c does not exist"
fi


</function_calls>
<function_calls>

shell
#!/bin/bash

List directory structure

ls -la examples/l3fwd/


</function_calls>
<function_calls>

shell
#!/bin/bash

Get actual file listing and content

echo "=== Files in examples/l3fwd/ ==="
find examples/l3fwd -type f -exec basename {} ; | sort

echo ""
echo "=== Reading l3fwd_fib.c in full ==="
cat examples/l3fwd/l3fwd_fib.c 2>&1 | head -300


</function_calls>
<function_calls>

shell
#!/bin/bash

Get exact line numbers 184-185 and 241-243 from l3fwd_fib.c

echo "=== Exact lines 184-185 ==="
sed -n '184,185p' examples/l3fwd/l3fwd_fib.c

echo ""
echo "=== Exact lines 241-243 ==="
sed -n '241,243p' examples/l3fwd/l3fwd_fib.c

echo ""
echo "=== Context: lines 175-195 ==="
sed -n '175,195p' examples/l3fwd/l3fwd_fib.c

echo ""
echo "=== Context: lines 235-250 ==="
sed -n '235,250p' examples/l3fwd/l3fwd_fib.c


</function_calls>

Based on the shell commands I've executed, let me now examine the key definitions:
<function_calls>

shell
#!/bin/bash

Search for where pkts_burst is used with rte_eth_rx_burst

echo "=== Searching for rte_eth_rx_burst usage in l3fwd_fib.c ==="
grep -n "rte_eth_rx_burst" examples/l3fwd/l3fwd_fib.c

echo ""
echo "=== Get context around those lines ==="
grep -n -B10 -A5 "rte_eth_rx_burst" examples/l3fwd/l3fwd_fib.c


</function_calls>
<function_calls>

shell
#!/bin/bash

Check the first 100 lines to see includes and global declarations

echo "=== First 100 lines ==="
head -100 examples/l3fwd/l3fwd_fib.c

echo ""
echo "=== Search for MAX_PKT_BURST and rx_burst_size in l3fwd_fib.c ==="
grep -n "MAX_PKT_BURST|rx_burst_size" examples/l3fwd/l3fwd_fib.c


</function_calls>
<function_calls>

shell
#!/bin/bash

Get all header files and search for these definitions

echo "=== All files in examples/l3fwd/ ==="
ls -1 examples/l3fwd/

echo ""
echo "=== Content of l3fwd_common.h ==="
if [ -f examples/l3fwd/l3fwd_common.h ]; then
cat examples/l3fwd/l3fwd_common.h
else
echo "File not found, listing all .h files:"
find examples/l3fwd -name "*.h" -exec echo "File: {}" ; -exec cat {} ;
fi


</function_calls>

Let me use a more reliable approach to find and read these files:
<function_calls>

shell
#!/bin/bash

Use Python to safely read and display files

python3 << 'PYEOF'
import os
import glob

Find all files in l3fwd

l3fwd_files = glob.glob('examples/l3fwd/**', recursive=True)
l3fwd_files = [f for f in l3fwd_files if os.path.isfile(f)]
print("Files in l3fwd:")
for f in sorted(l3fwd_files):
print(f" {f}")

Now read key files

print("\n" + "="*60)
print("Reading l3fwd_fib.c")
print("="*60)

if os.path.exists('examples/l3fwd/l3fwd_fib.c'):
with open('examples/l3fwd/l3fwd_fib.c', 'r') as f:
lines = f.readlines()
print(f"Total lines: {len(lines)}")

    # Print specific ranges
    print("\nLines 184-185:")
    for i in range(183, min(185, len(lines))):
        print(f"{i+1}: {lines[i]}", end='')
    
    print("\nLines 241-243:")
    for i in range(240, min(243, len(lines))):
        print(f"{i+1}: {lines[i]}", end='')
    
    print("\nLines 175-200 (context):")
    for i in range(174, min(200, len(lines))):
        print(f"{i+1}: {lines[i]}", end='')
        
    print("\nLines 235-250 (context):")
    for i in range(234, min(250, len(lines))):
        print(f"{i+1}: {lines[i]}", end='')

PYEOF


</function_calls>
<function_calls>

shell
#!/bin/bash

Search for MAX_PKT_BURST and rx_burst_size across all l3fwd files

python3 << 'PYEOF'
import os
import glob
import re

Find all C and H files

files = glob.glob('examples/l3fwd/**', recursive=True)
files = [f for f in files if os.path.isfile(f) and (f.endswith('.c') or f.endswith('.h'))]

print("Searching for MAX_PKT_BURST and rx_burst_size:")
print("="*60)

for filepath in sorted(files):
try:
with open(filepath, 'r') as f:
content = f.read()
lines = content.split('\n')

    found_max = False
    found_burst = False
    
    for i, line in enumerate(lines, 1):
        if 'MAX_PKT_BURST' in line:
            found_max = True
            print(f"\n{filepath}:{i}: {line}")
        if 'rx_burst_size' in line:
            found_burst = True
            print(f"\n{filepath}:{i}: {line}")
            
except Exception as e:
    pass

PYEOF


</function_calls>

Now let me get the full file content to make my assessment:
<function_calls>

shell
#!/bin/bash

Read the complete l3fwd_fib.c file using Python

python3 << 'PYEOF'
with open('examples/l3fwd/l3fwd_fib.c', 'r') as f:
lines = f.readlines()
for i, line in enumerate(lines, 1):
print(f"{i:3d}: {line}", end='')
PYEOF


</function_calls>

Perfect! Now let me search for MAX_PKT_BURST and rx_burst_size in related files:
<function_calls>

shell
#!/bin/bash

Check other l3fwd files for these symbols

python3 << 'PYEOF'
import os
import glob

files_to_check = glob.glob('examples/l3fwd/*.[ch]')

for filepath in sorted(files_to_check):
with open(filepath, 'r') as f:
content = f.read()

if 'MAX_PKT_BURST' in content or 'rx_burst_size' in content:
    print(f"\n{'='*60}")
    print(f"File: {filepath}")
    print('='*60)
    lines = content.split('\n')
    for i, line in enumerate(lines, 1):
        if 'MAX_PKT_BURST' in line or 'rx_burst_size' in line:
            # Print context
            start = max(0, i - 3)
            end = min(len(lines), i + 3)
            for j in range(start, end):
                marker = ">>>" if j == i - 1 else "   "
                print(f"{marker} {j+1:3d}: {lines[j]}")
            print()

PYEOF


</function_calls>

Now let me check if MAX_PKT_BURST might be coming from DPDK or other common headers:
<function_calls>

shell
#!/bin/bash

Look at the includes in l3fwd_fib.c to understand where MAX_PKT_BURST comes from

head -20 examples/l3fwd/l3fwd_fib.c
echo ""
echo "=== Searching entire codebase for MAX_PKT_BURST definition (not just usage) ==="
grep -r "define MAX_PKT_BURST" . 2>/dev/null | grep -v ".git"


</function_calls>

Let me also check for the actual rte_eth_rx_burst calls:
<function_calls>

shell
#!/bin/bash

Search for rte_eth_rx_burst in all l3fwd files

python3 << 'PYEOF'
import glob

files = glob.glob('examples/l3fwd/*.[ch]')

for filepath in sorted(files):
with open(filepath, 'r') as f:
lines = f.readlines()

for i, line in enumerate(lines, 1):
    if 'rte_eth_rx_burst' in line:
        print(f"\n{filepath}:{i}")
        start = max(0, i - 5)
        end = min(len(lines), i + 5)
        for j in range(start, end):
            marker = ">>>" if j == i - 1 else "   "
            print(f"{marker} {j+1:3d}: {lines[j]}", end='')

PYEOF


</function_calls>

Excellent! Now let me verify if there's any validation/clamping of rx_burst_size:
<function_calls>

shell
#!/bin/bash

Search for initialization and validation of rx_burst_size

python3 << 'PYEOF'
import glob

files = glob.glob('examples/l3fwd/*.[ch]')

print("Looking for rx_burst_size initialization and validation:")
print("="*70)

for filepath in sorted(files):
with open(filepath, 'r') as f:
content = f.read()
lines = content.split('\n')

for i, line in enumerate(lines, 1):
    if 'rx_burst_size' in line:
        # Show context
        start = max(0, i - 4)
        end = min(len(lines), i + 4)
        print(f"\n{filepath}:{i}")
        for j in range(start, end):
            marker = ">>>" if j == i - 1 else "   "
            print(f"{marker} {j+1:3d}: {lines[j]}")

PYEOF


</function_calls>

Now let me check all the l3fwd source files to get a complete picture:
<function_calls>

shell
#!/bin/bash

List ALL files in l3fwd with details

find examples/l3fwd -type f -exec wc -l {} + | sort -n

And cat them all for review

echo ""
echo "=== ALL l3fwd source files content ==="
find examples/l3fwd -type f ( -name ".c" -o -name ".h" ) | sort | while read f; do
echo ""
echo "================================"
echo "FILE: $f"
echo "================================"
cat "$f"
done


</function_calls>

Perfect! Now I have comprehensive visibility. Let me analyze the findings:

Based on my comprehensive verification of the codebase, I can now provide the rewritten review comment:

---

Clamp rx_burst_size to prevent potential stack buffer overflow

In fib_main_loop(), the RX burst size is unconstrained:

struct rte_mbuf *pkts_burst[MAX_PKT_BURST];
...
nb_rx = rte_eth_rx_burst(portid, queueid, pkts_burst, rx_burst_size);

If rx_burst_size is ever configured larger than MAX_PKT_BURST, this writes past the end of pkts_burst, causing a stack buffer overflow.

To make this safe independent of global configuration, clamp the burst size:

-        nb_rx = rte_eth_rx_burst(portid, queueid, pkts_burst,
-                rx_burst_size);
+        const uint16_t burst =
+            RTE_MIN((uint16_t)rx_burst_size, (uint16_t)MAX_PKT_BURST);
+        nb_rx = rte_eth_rx_burst(portid, queueid, pkts_burst, burst);

(or using RTE_DIM(pkts_burst)).

Even if configuration parsing restricts rx_burst_size, enforcing the bound here prevents subtle regressions.

Also applies to: line 241

🧹 Nitpick comments (18)

drivers/net/txgbe/base/txgbe_eeprom.c (1)

140-140: Semaphore mask narrowed to SWFLASH only across all EEPROM helpers

Using TXGBE_MNGSEM_SWFLASH alone in all EEPROM read/write entry points keeps the acquire/release pattern correct and consistent, and should just reduce semaphore contention assuming SWMBX is only required by mailbox-specific paths elsewhere. I don’t see any missed releases or new race windows introduced by this change.

If SWMBX is still used for other management mailbox operations in this driver, you might optionally consider documenting (e.g., in a comment near these helpers or in the MAC ops setup) that EEPROM accesses are intentionally serialized only on SWFLASH now, to avoid future confusion.

Also applies to: 167-167, 198-198, 223-223, 248-248, 275-275, 304-304, 329-329

examples/ip_reassembly/main.c (1)

887-892: Guard condition and log formatting can be tightened

The new guard is fine as defensive code, but two small tweaks would make it clearer and more consistent:

• Use >= with RTE_MAX_LCORE / RTE_MAX_QUEUES_PER_PORT since these macros are “max count” values, so the highest valid ID is typically max - 1.
• Add a newline to the log message to match surrounding RTE_LOG usage and avoid run‑on logs.

Suggested change:

-	/* Should never happen but check so that pool name won't be too long. */
-	if (lcore > RTE_MAX_LCORE || queue > RTE_MAX_QUEUES_PER_PORT) {
-		RTE_LOG(ERR, IP_RSMBL, "invalid lcore %u or queue %u",
-			lcore, queue);
+	/* Should never happen but check so that pool name won't be too long. */
+	if (lcore >= RTE_MAX_LCORE || queue >= RTE_MAX_QUEUES_PER_PORT) {
+		RTE_LOG(ERR, IP_RSMBL, "invalid lcore %u or queue %u\n",
+			lcore, queue);
 		return -1;
 	}

doc/guides/nics/mlx5.rst (1)

2812-2813: Clarify "aged flows reported only once" semantics.

The documented limitation states aged flows are reported only once with synchronous HW steering. Consider adding one sentence explaining whether repeated aging checks require flow recreation or if there is another mechanism to re-arm aging detection for the same flow.

Consider clarifying the limitation with example:

 #. When using synchronous flow API with :ref:`HW steering <mlx5_hws>`,
-   aged flows are reported only once.
+   aged flows are reported only once.
+   Subsequent age checks for the same flow require flow rule recreation
+   or re-configuration with ``rte_flow_configure()``.

This would prevent user confusion about the aging lifecycle.

examples/vdpa/main.c (1)

23-26: Compile‑time suffix length macro is sound and keeps limits self‑consistent

Using MAX_VDPA_STR_LEN as sizeof(RTE_STR(MAX_VDPA_SAMPLE_PORTS)) correctly tracks the maximum decimal width (plus NUL) of the port index and keeps the array math in one place, so later changes to MAX_VDPA_SAMPLE_PORTS won’t silently break the sizing logic. If you want extra belt‑and‑suspenders safety, you could add a static assert that MAX_PATH_LEN > MAX_VDPA_STR_LEN to fail early on configuration mistakes, but the current math is already correct.

drivers/net/cnxk/cn10k_rx.h (1)

1467-1537: Zero‑initialization of LMT and offset locals is safe; consider alternative to silence warnings

Initializing lmt_id, d_off, lbase, and laddr to zero (Lines 1467–1468) is safe and keeps behavior unchanged because:

• When NIX_RX_OFFLOAD_SECURITY_F is set, these variables are always overwritten in the guarded block before use.
• When security offload is disabled, subsequent uses remain under if (flags & NIX_RX_OFFLOAD_SECURITY_F) or if (flags & NIX_RX_OFFLOAD_SECURITY_F && loff) so the initialized values are never consulted.

If you want to avoid the extra instructions and still satisfy strict compilers, an optional alternative would be to:

• Wrap the final if (flags & NIX_RX_OFFLOAD_SECURITY_F && loff) and related LMT flush logic in a narrower scope or helper that’s only compiled when security offload is built in, so the compiler can see definitive initialization paths.

drivers/net/nbl/nbl_dev/nbl_dev.h (1)

98-98: VLAN offload setter prototype is fine; attribute use in header is optional

The declaration is consistent with the definition and its use as a device op; no functional issues. If you want to keep the header a bit cleaner, you could drop __rte_unused on the parameters here and keep it only on the definition, since callers conceptually use both arguments.

-int nbl_vlan_offload_set(__rte_unused struct rte_eth_dev *dev, __rte_unused int mask);
+int nbl_vlan_offload_set(struct rte_eth_dev *dev, int mask);

drivers/net/nbl/nbl_dev/nbl_dev.c (1)

761-768: No-op nbl_vlan_offload_set is reasonable; consider mask validation / clearer contract

Given the comment, a no-op implementation that always returns 0 is fine if both RX and TX VLAN handling are entirely driven by rxmode/txmode.offloads in your fast paths, with no extra hardware programming needed here.

Two follow-ups you might consider:

• Validate mask against the VLAN offload modes you actually support and return -ENOTSUP (or at least log) when unsupported bits are requested, instead of silently accepting everything.
• Extend the comment to mention TX behavior as well (if no HW config is needed there either), so it’s clear to future readers why this callback is intentionally a stub.

Please double-check against the DPDK ethdev API/version you are targeting that:

• A do-nothing vlan_offload_set is acceptable when capabilities are advertised but no HW state needs updating, and
• The mask bits passed here are already sanitized against your *_offload_capa so additional validation isn’t required unless you want stricter behavior.

drivers/net/txgbe/base/txgbe_type.h (1)

779-791: Mailbox struct extension for host-interface commands looks good

Adding host_interface_command to struct txgbe_mbx_info with the shared SP/AML signature cleanly abstracts firmware host-interface calls behind the mailbox interface. Consider adding a short comment above this member indicating it is the unified FW host-interface command hook for clarity.

drivers/net/mlx5/mlx5_flow_flex.c (1)

507-577: OFFSET-mode WA logic is sound; only minor readability nits

The new header_length_field_mode_wa‑gated block in the OFFSET path (extra bounds check, offset bump, and the dword‑wrap avoidance) is consistent with the earlier wmax/mask checks and keeps the arithmetic well‑defined. Setting header_length_field_offset_mode = !attr->header_length_field_mode_wa cleanly exposes the firmware variant to DevX.

If you want to reduce cognitive load around the unsigned subtraction, you could introduce a small temporary (e.g. uint32_t diff = attr->header_length_mask_width - msb;) before comparing to offset, but functionally this looks correct.

Please validate on at least one pre‑CX8 (WA‑required) and one CX8+ firmware that the programmed FLEX PARSE GRAPH behaves as expected for OFFSET mode (no off‑by‑one or wrap when the mask width is small).

examples/server_node_efd/shared/common.h (1)

58-67: Based on my verification, I can now provide the rewritten review comment. The original review significantly overstates the severity of the thread-safety concern given that the function is only called during initialization/startup phases, not in worker threads or hot paths.

---

Buffer size change is correct; thread-safety concern is overstated given initialization-only usage.

The change to use RTE_RING_NAMESIZE is appropriate for ring naming. However, the original review's "critical thread-safety issue" is misleading:

1. Thread-safety not critical here: The function is called only during initialization (efd_server/init.c:188 and efd_node/node.c:331), not in worker thread contexts. Each call immediately passes the buffer to rte_ring_create() or rte_ring_lookup() without storing it, mitigating any practical race condition risk.

2. Buffer size is adequate: Template "MProc_Node_15_RX" (with MAX_NODES=16) expands to 16 chars + null terminator = 17 bytes, well within RTE_RING_NAMESIZE (typically 32 bytes).

3. Comment inaccuracy: Line 59-60 states "maximum 3 digits" but with MAX_NODES=16, the actual maximum is 2 digits (node IDs 0-15). Update comment to reflect this.

Using __rte_thread_local is unnecessary given the initialization-only usage pattern and would add unnecessary overhead.

drivers/bus/fslmc/fslmc_bus.c (1)

242-305: Const-qualification of t_ptr is fine; optional cleanup of sep handling.

Changing t_ptr to const char * is correct since it’s only read. While not introduced here, note that when sep_exists is true, sep still points at the separator (':' or '=') and is used in the device‑name checks (e.g. strncmp("dpni", sep, 4)), which means forms like "fslmc:dpni.1" / "name=dpni.1" won’t match as the comment suggests. If those forms are expected, consider advancing sep past the separator before validation.

drivers/net/memif/rte_eth_memif.c (1)

1837-1869: Const update is good; re-check faccessat dirfd usage.

Making tmp const char * is appropriate since it’s only used to locate the last '/' and for index math; no behavior change.

Separately (pre‑existing), faccessat is called as:

if (dir == NULL || (faccessat(-1, dir, F_OK | R_OK | W_OK, AT_EACCESS) < 0)) {
    ...
}

On POSIX, the first argument is normally either a valid dir fd or AT_FDCWD, not -1. Using -1 risks EBADF and treating valid directories as invalid. It may be worth switching to AT_FDCWD here (or plain access() if appropriate) for correctness and portability.

doc/guides/freebsd_gsg/build_dpdk.rst (1)

19-29: FreeBSD pyelftools / Python 3.11 updates and note formatting are consistent.

Switching to py311-pyelftools, updating the corresponding pkg install example, and fixing the Sphinx directive to .. note:: keeps the documentation accurate for Python 3.11 and valid for Sphinx builds.

examples/l3fwd-power/main.c (1)

1504-1505: Clarify and harden --eth-link-speed parsing/validation

The new option is wired correctly into lgopts and port_conf.link_speeds, but the parsing behavior is a bit inconsistent with other numeric options:

• speed_num is parsed with atoi() and only 10M/100M are rejected explicitly; other invalid or out‑of‑range values are silently ignored (no error, no log), which differs from the stricter parse_uint() handling used elsewhere.
• Non‑numeric values (e.g. --eth-link-speed=foo) will be treated as 0 and effectively ignored without feedback.
• The help text does not indicate units, valid values, or that 10M/100M are unsupported.

Consider:

• Reusing parse_uint() (with a sensible max, e.g. highest supported speed) or strtoul() with error checks, and
• Treating unsupported speeds similarly to 10M/100M (print error + usage and fail), and
• Expanding the help string to document accepted speeds and units.

This keeps CLI behavior predictable and aligned with other options.

Also applies to: 1746-1747, 1753-1754, 1773-1774, 1958-1970

examples/l3fwd/l3fwd_common.h (1)

28-30: Document/centralize bounds for rx_burst_size / tx_burst_size

The switch from a compile-time threshold to tx_burst_size in send_packetsx4() plus the new externs is reasonable, and the local TX buffer logic still safely clamps to MAX_PKT_BURST.

However, now both RX and TX code paths depend on these global burst sizes being kept within sane limits (e.g., not larger than the various MAX_* capacities used for arrays and SW buffers elsewhere in l3fwd). It would be good to:

• Clearly document the allowed range for rx_burst_size / tx_burst_size, and
• Clamp or validate them once in the CLI parsing (e.g., <= MAX_PKT_BURST), rather than assuming all callers know the implicit limits.

This keeps the rest of the code (including this function) obviously safe and easier to reason about.

Also applies to: 77-78

examples/l3fwd/main.c (3)

404-405: CLI help for new burst/link-speed options is accurate; consider documenting “0” semantics

The added usage lines for --rx-burst, --tx-burst, and --eth-link-speed correctly match the option names and default values passed into the fprintf call.

Given parse_pkt_burst() treats --rx-burst 0 as “use PMD-recommended RX burst” and --tx-burst 0 as “keep default and log”, you might optionally spell out the special meaning of 0 in the help text to avoid surprises for users.

Also applies to: 428-429, 433-437, 468-469

---

703-750: parse_pkt_burst logic is sound; only minor robustness concern around port 0

The refactored parse_pkt_burst() cleanly:

• Parses and clamps user input to MAX_PKT_BURST.
• Updates the pointed-to burst_sz for positive values.
• For RX and value 0, queries dev_info.default_rxportconf.burst_size and uses it when valid and within bounds.
• For TX and value 0, leaves *burst_sz unchanged but logs that the default will be used.

One minor robustness point: using a hard-coded port_id = 0 in rte_eth_dev_info_get(0, &dev_info) assumes port 0 exists and its recommendation is representative. If you want this to be more general, you could consider using the first available or first enabled port instead of always 0.

---

881-882: New --eth-link-speed and RX/TX burst argument handling integrates cleanly; consider stricter validation for speeds

The added cases for CMD_LINK_OPT_ETH_LINK_SPEED_NUM, CMD_LINE_OPT_PKT_RX_BURST_NUM, and CMD_LINE_OPT_PKT_TX_BURST_NUM in parse_args() are wired correctly to the new options and helpers:

• --eth-link-speed rejects 10/100 Mbps explicitly, then uses rte_eth_speed_bitflag(speed_num, 0) to set port_conf.link_speeds when it returns a non-zero flag.
• --rx-burst / --tx-burst delegate to parse_pkt_burst() with the appropriate is_rx_burst flag and target global.

Behaviour-wise, invalid or unsupported eth-link-speed values (i.e., those mapping to 0 from rte_eth_speed_bitflag) are silently ignored. If you want stricter UX, you could additionally detect that case and print usage / return an error, instead of quietly falling back to autonegotiation.

Also applies to: 930-940, 949-955

📜 Review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between ef98b88 and b17da19.

⛔ Files ignored due to path filters (2)

• doc/guides/prog_guide/img/kni_traffic_flow.png is excluded by !**/*.png
• doc/guides/prog_guide/img/pkt_flow_kni.png is excluded by !**/*.png

📒 Files selected for processing (70)

• MAINTAINERS (1 hunks)
• VERSION (1 hunks)
• app/proc-info/main.c (1 hunks)
• app/test-pmd/csumonly.c (1 hunks)
• app/test/test_debug.c (2 hunks)
• doc/api/meson.build (3 hunks)
• doc/guides/cryptodevs/ionic.rst (2 hunks)
• doc/guides/freebsd_gsg/build_dpdk.rst (1 hunks)
• doc/guides/linux_gsg/amd_platform.rst (2 hunks)
• doc/guides/meson.build (1 hunks)
• doc/guides/nics/i40e.rst (2 hunks)
• doc/guides/nics/ice.rst (2 hunks)
• doc/guides/nics/ionic.rst (2 hunks)
• doc/guides/nics/mlx5.rst (11 hunks)
• doc/guides/rel_notes/release_25_11.rst (6 hunks)
• doc/guides/sample_app_ug/l3_forward.rst (2 hunks)
• doc/guides/windows_gsg/build_dpdk.rst (4 hunks)
• drivers/bus/fslmc/fslmc_bus.c (1 hunks)
• drivers/bus/ifpga/ifpga_bus.c (1 hunks)
• drivers/bus/uacce/uacce.c (1 hunks)
• drivers/common/mlx5/mlx5_devx_cmds.c (2 hunks)
• drivers/common/mlx5/mlx5_devx_cmds.h (2 hunks)
• drivers/common/mlx5/mlx5_prm.h (4 hunks)
• drivers/common/qat/qat_device.c (3 hunks)
• drivers/common/qat/qat_device.h (1 hunks)
• drivers/compress/qat/qat_comp_pmd.c (1 hunks)
• drivers/crypto/caam_jr/caam_jr_uio.c (1 hunks)
• drivers/crypto/qat/qat_asym.c (1 hunks)
• drivers/crypto/qat/qat_sym.c (1 hunks)
• drivers/event/cnxk/cn10k_eventdev.c (3 hunks)
• drivers/event/cnxk/cn10k_worker.h (1 hunks)
• drivers/event/cnxk/cn20k_eventdev.c (3 hunks)
• drivers/event/cnxk/cn20k_worker.h (1 hunks)
• drivers/net/cnxk/cn10k_rx.h (2 hunks)
• drivers/net/cnxk/cn20k_rx.h (2 hunks)
• drivers/net/enetfec/enet_uio.c (1 hunks)
• drivers/net/hns3/hns3_rxtx.c (2 hunks)
• drivers/net/intel/iavf/iavf_ethdev.c (1 hunks)
• drivers/net/memif/rte_eth_memif.c (1 hunks)
• drivers/net/mlx5/mlx5.c (2 hunks)
• drivers/net/mlx5/mlx5_flow_flex.c (2 hunks)
• drivers/net/nbl/nbl_dev/nbl_dev.c (1 hunks)
• drivers/net/nbl/nbl_dev/nbl_dev.h (1 hunks)
• drivers/net/nbl/nbl_ethdev.c (1 hunks)
• drivers/net/nbl/nbl_hw/nbl_resource.h (2 hunks)
• drivers/net/nbl/nbl_hw/nbl_txrx.c (3 hunks)
• drivers/net/ngbe/ngbe_rxtx.c (1 hunks)
• drivers/net/ntnic/ntnic_ethdev.c (0 hunks)
• drivers/net/softnic/rte_eth_softnic.c (0 hunks)
• drivers/net/txgbe/base/txgbe_aml.c (2 hunks)
• drivers/net/txgbe/base/txgbe_aml40.c (2 hunks)
• drivers/net/txgbe/base/txgbe_eeprom.c (8 hunks)
• drivers/net/txgbe/base/txgbe_hw.c (2 hunks)
• drivers/net/txgbe/base/txgbe_mng.c (11 hunks)
• drivers/net/txgbe/base/txgbe_mng.h (1 hunks)
• drivers/net/txgbe/base/txgbe_type.h (1 hunks)
• drivers/net/txgbe/txgbe_rxtx.c (1 hunks)
• examples/ip_reassembly/main.c (1 hunks)
• examples/l3fwd-power/main.c (4 hunks)
• examples/l3fwd/l3fwd.h (2 hunks)
• examples/l3fwd/l3fwd_acl.c (1 hunks)
• examples/l3fwd/l3fwd_common.h (2 hunks)
• examples/l3fwd/l3fwd_em.c (1 hunks)
• examples/l3fwd/l3fwd_fib.c (1 hunks)
• examples/l3fwd/l3fwd_lpm.c (1 hunks)
• examples/l3fwd/main.c (15 hunks)
• examples/meson.build (1 hunks)
• examples/server_node_efd/efd_server/main.c (1 hunks)
• examples/server_node_efd/shared/common.h (1 hunks)
• examples/vdpa/main.c (3 hunks)

💤 Files with no reviewable changes (2)

• drivers/net/softnic/rte_eth_softnic.c
• drivers/net/ntnic/ntnic_ethdev.c

🧰 Additional context used

🧬 Code graph analysis (8)

drivers/common/qat/qat_device.h (1)

drivers/common/qat/qat_device.c (1)

• qat_dev_cmdline_get_val (176-184)

drivers/net/txgbe/base/txgbe_aml40.c (1)

drivers/net/txgbe/base/txgbe_mng.c (1)

• txgbe_host_interface_command_aml (163-272)

drivers/net/txgbe/base/txgbe_aml.c (1)

drivers/net/txgbe/base/txgbe_mng.c (1)

• txgbe_host_interface_command_aml (163-272)

drivers/net/txgbe/base/txgbe_mng.h (1)

drivers/net/txgbe/base/txgbe_mng.c (2)

• txgbe_host_interface_command_sp (99-161)
• txgbe_host_interface_command_aml (163-272)

drivers/net/nbl/nbl_ethdev.c (1)

drivers/net/nbl/nbl_dev/nbl_dev.c (1)

• nbl_vlan_offload_set (761-768)

drivers/net/txgbe/base/txgbe_hw.c (1)

drivers/net/txgbe/base/txgbe_mng.c (1)

• txgbe_host_interface_command_sp (99-161)

drivers/net/nbl/nbl_dev/nbl_dev.h (1)

drivers/net/nbl/nbl_dev/nbl_dev.c (1)

• nbl_vlan_offload_set (761-768)

drivers/net/nbl/nbl_dev/nbl_dev.c (2)

lib/ethdev/ethdev_driver.h (1)

• rte_eth_dev (72-117)

drivers/net/nbl/nbl_hw/nbl_txrx_ops.h (2)

• int (19-29)
• int (31-89)

[coderabbitai]

⚠️ Potential issue | 🟠 Major

🧩 Analysis chain

🏁 Script executed:

#!/bin/bash
# First, let's find and read the file around the specified lines
echo "=== Reading lines 520-580 of app/test-pmd/csumonly.c ==="
sed -n '520,580p' app/test-pmd/csumonly.c | cat -n

Repository: ovsrobot/dpdk

Length of output: 2286

---

🏁 Script executed:

#!/bin/bash
# Search for get_ethertype_by_ptype function
echo "=== Searching for get_ethertype_by_ptype function ==="
rg -n "get_ethertype_by_ptype" app/test-pmd/csumonly.c -A 40

echo ""
echo "=== Checking lines 563-571 (Also applies to section) ==="
sed -n '555,575p' app/test-pmd/csumonly.c | cat -n

Repository: ovsrobot/dpdk

Length of output: 4462

---

🏁 Script executed:

#!/bin/bash
# Search for where RTE_PTYPE_INNER_L3_IPV4_EXT_UNKNOWN is defined or used
echo "=== Searching for EXT_UNKNOWN ptype usage in the file ==="
rg -n "EXT_UNKNOWN" app/test-pmd/csumonly.c

echo ""
echo "=== Checking if these are standard DPDK constants ==="
rg -n "RTE_PTYPE_INNER_L3_IPV4_EXT_UNKNOWN|RTE_PTYPE_INNER_L3_IPV6_EXT_UNKNOWN" . --type=c | head -20

Repository: ovsrobot/dpdk

Length of output: 1993

---

Based on my verification, the review comment is correct and valid. I've confirmed:

1. The *_EXT_UNKNOWN ptypes are real DPDK constants defined in lib/mbuf/rte_mbuf_ptype.h (lines 571, 592) and actively used by multiple hardware drivers (axgbe, zxdh, txgbe).

2. The inconsistency is confirmed: get_ethertype_by_ptype() explicitly handles RTE_PTYPE_INNER_L3_IPV4_EXT_UNKNOWN and RTE_PTYPE_INNER_L3_IPV6_EXT_UNKNOWN (lines 480, 487), correctly mapping them to IPv4/IPv6 ethertypes. However, parse_l4_proto() has no cases for these ptypes when in_tunnel=true, causing align_ptype to be set to 0, which skips both IPv4 and IPv6 checks and returns 0.

3. The impact is real: This affects L4 protocol detection for tunneled packets with these ptypes, breaking checksum offload and TSO handling as the reviewer stated.

The review comment's analysis and suggested fix are sound. The comment should be kept with classification since this is a genuine bug affecting actual hardware-generated packet types.

---

Handle *_EXT_UNKNOWN inner ptypes in parse_l4_proto

The tunnel-aware refactor generally makes sense, but the in_tunnel mapping currently ignores some inner L3 ptypes that this file otherwise treats as valid IPv4/IPv6:

• get_ethertype_by_ptype() has explicit cases for RTE_PTYPE_INNER_L3_IPV4_EXT_UNKNOWN and RTE_PTYPE_INNER_L3_IPV6_EXT_UNKNOWN (lines 480, 487), mapping them to IPv4/IPv6 ethertypes.
• In parse_l4_proto(), when in_tunnel is true, mask_ptype = ptype & RTE_PTYPE_INNER_L3_MASK; is only checked against INNER_L3_IPV4, INNER_L3_IPV4_EXT, INNER_L3_IPV6, and INNER_L3_IPV6_EXT. For *_EXT_UNKNOWN values, align_ptype becomes 0, so both IPv4 and IPv6 branches are skipped and the function returns 0.

Effect: Tunneled packets whose inner header is tagged as *_EXT_UNKNOWN (generated by hardware drivers like axgbe and zxdh) will no longer have their L4 protocol detected, so they won't go through the UDP/TCP/SCTP checksum and TSO logic even though they were previously recognized as IPv4/IPv6.

Consider extending the mapping, for example:

uint32_t mask_ptype = ptype & RTE_PTYPE_INNER_L3_MASK;

switch (mask_ptype) {
case RTE_PTYPE_INNER_L3_IPV4:
case RTE_PTYPE_INNER_L3_IPV4_EXT:
case RTE_PTYPE_INNER_L3_IPV4_EXT_UNKNOWN:
    align_ptype = RTE_PTYPE_L3_IPV4_EXT; /* or L3_IPV4 if you prefer */
    break;
case RTE_PTYPE_INNER_L3_IPV6:
case RTE_PTYPE_INNER_L3_IPV6_EXT:
case RTE_PTYPE_INNER_L3_IPV6_EXT_UNKNOWN:
    align_ptype = RTE_PTYPE_L3_IPV6_EXT;
    break;
default:
    align_ptype = 0;
    break;
}

(or any equivalent mapping consistent with how you want to treat "EXT_UNKNOWN").

This keeps inner handling aligned with the rest of the file and avoids unexpectedly disabling checksum handling for a subset of tunneled flows.

Also applies to: 563-571

🤖 Prompt for AI Agents

In app/test-pmd/csumonly.c around lines 528-547 (and similarly at 563-571), the
in_tunnel branch masks inner ptype but does not handle
RTE_PTYPE_INNER_L3_IPV4_EXT_UNKNOWN and RTE_PTYPE_INNER_L3_IPV6_EXT_UNKNOWN,
causing align_ptype to become 0 and skipping IPv4/IPv6 L4 protocol detection;
update the in_tunnel mapping to include the *_EXT_UNKNOWN inner ptypes and map
them to the corresponding outer L3 type (e.g., map INNER_L3_IPV4_EXT_UNKNOWN to
RTE_PTYPE_L3_IPV4_EXT and INNER_L3_IPV6_EXT_UNKNOWN to RTE_PTYPE_L3_IPV6_EXT) so
checksum/TSO logic runs for tunneled packets with those hardware-generated
ptypes.

[coderabbitai]

⚠️ Potential issue | 🟡 Minor

Fix grammar in UNCORE section reference.

Line 104 has a grammar issue: "Please refer the tuning guides" should be "Please refer to the tuning guides".

Apply this diff to fix the grammar:

-Please refer the tuning guides to enable ``HSMP`` and DPDK power management guide.
+Please refer to the tuning guides to enable ``HSMP`` and refer to the DPDK power management guide.

🤖 Prompt for AI Agents

In doc/guides/linux_gsg/amd_platform.rst around lines 99 to 105, fix the grammar
in the UNCORE section by changing the phrase "Please refer the tuning guides" to
"Please refer to the tuning guides" so the sentence reads correctly and
references the tuning guides.

[coderabbitai]

⚠️ Potential issue | 🟡 Minor

🧩 Analysis chain

🏁 Script executed:

#!/bin/bash
# First, let's examine the file to see both links (line 29 and 69)
cat -n doc/guides/windows_gsg/build_dpdk.rst | sed -n '20,75p'

Repository: ovsrobot/dpdk

Length of output: 2207

---

🌐 Web query:

Does mesonbuild.com support HTTPS protocol for its documentation pages?

💡 Result:

Yes — the Meson documentation is served over HTTPS (e.g. https://mesonbuild.com/Reference-manual.html). [1][2]

Sources:
[1] mesonbuild.com Reference manual.
[2] mesonbuild/meson commit noting use of https for mesonbuild.com.

---

Upgrade Meson documentation links from HTTP to HTTPS for consistency and security.

The review comment is valid. Line 29 correctly uses HTTPS for the LLVM link (https://releases.llvm.org), while lines 66 and 69 both use HTTP for the Meson documentation links. Web verification confirms that mesonbuild.com supports HTTPS, making this an appropriate upgrade for consistency with modern security practices and the HTTPS changes already made to LLVM documentation in this PR.

Both occurrences should be updated:

• Line 66: http://mesonbuild.com/Getting-meson.html → https://mesonbuild.com/Getting-meson.html
• Line 69: http://mesonbuild.com/Getting-meson.html#installing-meson-and-ninja-with-the-msi-installer → https://mesonbuild.com/Getting-meson.html#installing-meson-and-ninja-with-the-msi-installer

🤖 Prompt for AI Agents

doc/guides/windows_gsg/build_dpdk.rst lines 66 and 69: replace the Meson links
that currently use http with https to match the rest of the docs and ensure
secure links; specifically change http://mesonbuild.com/Getting-meson.html →
https://mesonbuild.com/Getting-meson.html (line 66) and
http://mesonbuild.com/Getting-meson.html#installing-meson-and-ninja-with-the-msi-installer
→
https://mesonbuild.com/Getting-meson.html#installing-meson-and-ninja-with-the-msi-installer
(line 69).

[coderabbitai]

⚠️ Potential issue | 🟠 Major

Use the strstr result when parsing the number to preserve semantics

The new implementation:

return strstr(filename, match) != NULL &&
       sscanf(filename + strlen(match), "%d", number) > 0;

changes behavior compared to the usual pattern of parsing from the position where match is actually found. If match appears not at the start of filename, this will parse from filename + strlen(match) instead of from just after the matched substring, which conflicts with the documented behavior (“contains a certain substring… extracts the number following the substring”) and with what the old code almost certainly did.

Current sysfs names ("uioX", "fsl-jrX") happen to have match at the beginning, so this likely works today, but it silently narrows the accepted patterns and may break if naming ever changes.

To keep the compact style while preserving semantics, consider:

 static bool
 file_name_match_extract(const char filename[], const char match[], int *number)
 {
-	/* substring <match> was found in <filename>
-	 * read number following <match> substring in <filename>
-	 */
-	return strstr(filename, match) != NULL &&
-		sscanf(filename + strlen(match), "%d", number) > 0;
+	const char *substr = strstr(filename, match);
+
+	/* substring <match> was found in <filename>
+	 * read number following <match> substring in <filename>
+	 */
+	return substr != NULL &&
+		sscanf(substr + strlen(match), "%d", number) > 0;
 }

This keeps the simplification but maintains the intended “number after the matched substring” behavior.

🤖 Prompt for AI Agents

In drivers/crypto/caam_jr/caam_jr_uio.c around lines 106 to 114, the current
code calls strstr(filename, match) only to test for existence but then uses
filename + strlen(match) when parsing the number, which parses from the wrong
position if match is not at the start; fix by storing the result of strstr in a
pointer, check that pointer is not NULL, and pass pointer + strlen(match) to
sscanf to parse the trailing number so the parsed number starts immediately
after the actual matched substring.

[coderabbitai]

⚠️ Potential issue | 🟠 Major

send_single_packet is keyed off rx_burst_size, ignoring tx_burst_size

send_single_packet() is part of the TX path, but the flush threshold and burst size passed to send_burst() still use rx_burst_size. With the new independent --rx-burst / --tx-burst options, the TX-side knob has no effect on this path, which is inconsistent with the rest of the example and user expectations.

I recommend switching this to use tx_burst_size and making it visible here:

 extern uint32_t max_pkt_len;
-extern uint32_t rx_burst_size;
+extern uint32_t rx_burst_size;
+extern uint32_t tx_burst_size;
 extern uint32_t mb_mempool_cache_size;
@@
-    /* enough pkts to be sent */
-    if (unlikely(len == rx_burst_size)) {
-        send_burst(qconf, rx_burst_size, port);
+    /* enough pkts to be sent */
+    if (unlikely(len == tx_burst_size)) {
+        send_burst(qconf, tx_burst_size, port);
         len = 0;
     }

Also applies to: 151-152

🤖 Prompt for AI Agents

In examples/l3fwd/l3fwd.h around lines 115 (and also update usages at 151-152),
the TX path's send_single_packet is incorrectly keyed off rx_burst_size; declare
and use tx_burst_size instead so the TX flush threshold and burst size use the
independent TX knob. Replace the extern uint32_t rx_burst_size reference here
with extern uint32_t tx_burst_size (and update the send_single_packet calls at
lines ~151-152 to pass tx_burst_size/tx flush threshold) so TX-side behavior
honors the --tx-burst option.