[PWCI] "[v4] event/cnxk: fix offload flags" #497
Conversation
Enhance the documentation by adding information about limitations specific to the synchronous API when used with hardware steering. This update provides users with a more comprehensive understanding of the constraints in this configuration. Signed-off-by: Maayan Kashani <mkashani@nvidia.com> Signed-off-by: Bing Zhao <bingz@nvidia.com>
Add tested, and hence recommended, firmware and other versions for i40e and ice drivers. In the process remove version inform for obsolete DPDK releases. Signed-off-by: Hailin Xu <hailinx.xu@intel.com> Acked-by: Bruce Richardson <bruce.richardson@intel.com>
There is the updated firmware providing the new capability bit "header_length_field_offset_mode". If this bit is set the length field offset in flex parser configuration should not be adjusted by the supported field mask left margin, and the bit "header_length_field_offset_mode" should be set in configuration command on the flex parser creation firmware call. Fixes: b04b06f ("net/mlx5: fix flex item header length field translation") Cc: stable@dpdk.org Signed-off-by: Viacheslav Ovsiienko <viacheslavo@nvidia.com>
The update of flow engine devargs introduced a regression with untrusted VFs/SFs. Using HWS engine caused a degradation in probing 1K SFs, because memzone segments exceeds maximum 2560. Fixes: 53fdc23 ("common/mlx5: read SW steering capability bits") Fixes: d1ac7b6 ("net/mlx5: update flow devargs handling for future HW") Signed-off-by: Raslan Darawsheh <rasland@nvidia.com>
Count flow action is supported on root table with HW Steering flow engine with upstream drivers/libraries and drivers/libraries packaged with recently released DOCA. This patch updates relevant docs with minimum DOCA version. Signed-off-by: Dariusz Sosnowski <dsosnowski@nvidia.com> Acked-by: Bing Zhao <bingz@nvidia.com>
Previously, the Tx burst size in l3fwd was fixed at 256, which could lead to suboptimal performance in certain scenarios. This patch introduces separate --rx-burst and --tx-burst options to explicitly configure Rx and Tx burst sizes. By default, the Tx burst size now matches the Rx burst size for better efficiency and pipeline balance. Fixes: d5c4897 ("examples/l3fwd: add option to set Rx burst size") Signed-off-by: Sivaprasad Tummala <sivaprasad.tummala@amd.com> Tested-by: Venkat Kumar Ande <venkatkumar.ande@amd.com> Tested-by: Dengdui Huang <huangdengdui@huawei.com> Tested-by: Pavan Nikhilesh <pbhagavatula@marvell.com> Acked-by: Chengwen Feng <fengchengwen@huawei.com>
Currently, l3fwd starts in auto-negotiation mode, but it may fail to link up when auto-negotiation is not supported. Therefore, it is necessary to support starting with a specified speed for port. Additionally, this patch does not support changing the duplex mode. So speeds like 10M, 100M are not configurable using this method. Signed-off-by: Dengdui Huang <huangdengdui@huawei.com> Reviewed-by: Chengwen Feng <fengchengwen@huawei.com>
Currently, l3fwd-power starts in auto-negotiation mode, but it may fail to link up when auto-negotiation is not supported. Therefore, it is necessary to support starting with a specified speed for port. Additionally, this patch does not support changing the duplex mode. So speeds like 10M, 100M are not configurable using this method. Signed-off-by: Dengdui Huang <huangdengdui@huawei.com> Reviewed-by: Chengwen Feng <fengchengwen@huawei.com>
If format-truncation is enabled, the compiler detects a string overflow
since the snprintf() is putting ethernet address and new line
in buffer only sized for the address.
Since get_rx_queue_name() is used to create a ring name.
The buffer should be sized to be a valid ring name.
This fixes some format-overflow warnings and also corrects
for future errors.
In file included from ../examples/server_node_efd/efd_server/main.c:31:
In function ‘get_printable_mac_addr’,
inlined from ‘do_stats_display’ at ../examples/server_node_efd/efd_server/main.c:136:3:
../lib/net/rte_ether.h:248:36: warning: ‘snprintf’ output truncated before the last format character [-Wformat-truncation=]
248 | #define RTE_ETHER_ADDR_PRT_FMT "%02X:%02X:%02X:%02X:%02X:%02X"
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
../examples/server_node_efd/efd_server/main.c:86:33: note: in expansion of macro ‘RTE_ETHER_ADDR_PRT_FMT’
86 | RTE_ETHER_ADDR_PRT_FMT "\n",
| ^~~~~~~~~~~~~~~~~~~~~~
../examples/server_node_efd/efd_server/main.c: In function ‘do_stats_display’:
../examples/server_node_efd/efd_server/main.c:86:59: note: format string is defined here
86 | RTE_ETHER_ADDR_PRT_FMT "\n",
|
Fixes: 39aad0e ("examples/flow_distributor: new example to demonstrate EFD")
Cc: stable@dpdk.org
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
Acked-by: Bruce Richardson <bruce.richardson@intel.com>
The ifname is limited to 128 characters, but it would allow up
to 128 characters as prefix then could overflow creating ifname.
Change to limit path prefix (iface) to 123 (128 - sizeof("1024"))
to avoid possible format overflow
../examples/vdpa/main.c:501:76: warning: ‘snprintf’ output may be truncated before the last format character [-Wformat-truncation=]
501 | snprintf(vports[devcnt].ifname, MAX_PATH_LEN, "%s%d",
| ^
../examples/vdpa/main.c:501:25: note: ‘snprintf’ output between 2 and 139 bytes into a destination of size 128
501 | snprintf(vports[devcnt].ifname, MAX_PATH_LEN, "%s%d",
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
502 | iface, devcnt);
|
Fixes: 38f8ab0 ("vhost: make vDPA framework bus agnostic")
Cc: stable@dpdk.org
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
Acked-by: Bruce Richardson <bruce.richardson@intel.com>
In theory, lcore and queue could be so large that mbuf pool name could overflow. But that can never happen since lcore and queue will be in range. Add a check so that static tools know that. Format overflow warnings seen on older versions of Gcc only. Signed-off-by: Stephen Hemminger <stephen@networkplumber.org> Acked-by: Konstantin Ananyev <konstantin.ananyev@huawei.com> Acked-by: Bruce Richardson <bruce.richardson@intel.com>
There were several hidden bugs in examples because format truncation warning was disabled. Signed-off-by: Stephen Hemminger <stephen@networkplumber.org> Acked-by: Bruce Richardson <bruce.richardson@intel.com>
After removing callback checks from ethdev fast path, some drivers crashed because tx_pkt_prepare was set to NULL. Some drivers (hns3, ngbe, txgbe) need to use rte_eth_tx_pkt_prepare_dummy when configuring queues. Other drivers (ntnic, softnic) does not need to set tx_pkt_prepare as it was set by eth_dev_set_dummy_fops() called by rte_eth_dev_allocate(). Bugzilla ID: 1834 Fixes: 066f3d9 ("ethdev: remove callback checks from fast path") Reported-by: Jiawen Wu <jiawenwu@trustnetic.com> Signed-off-by: Thomas Monjalon <thomas@monjalon.net> Reviewed-by: Morten Brørup <mb@smartsharesystems.com> Tested-by: Jiawen Wu <jiawenwu@trustnetic.com>
The Pollara 400 AI NIC is supported without any PMD changes. Add a link to the product brief. Cc: stable@dpdk.org Signed-off-by: Andrew Boyer <andrew.boyer@amd.com>
changes: 1. fix spelling from `SIENNA` to `SIENA` 2. add tuning guide for zen5 AMD Epyc 9005 3. add uncore power details 4. update on using AMD Solarflare X4 and X2 Signed-off-by: Vipin Varghese <vipin.varghese@amd.com> Tested-by: Thiyagarajan P <thiyagarajan.p@amd.com>
Updated some external links and removed a note which does not apply to MSVC builds anymore. Also reworded a sentence clarifying how to open a Visual Studio Developer Command Prompt from CMD and Powershell, as the original text could induce people to run VsDevCmd.bat from a Powershell prompt, which does not work. Signed-off-by: Andre Muezerie <andremue@linux.microsoft.com>
The note about the prefix of the package pyelftools was not showed in the documentation output because the syntax was missing a colon, so it was considered as a simple comment in the source file. Fixes: 9e6f75e ("doc: update build section of FreeBSD guide") Cc: stable@dpdk.org Signed-off-by: Thomas Monjalon <thomas@monjalon.net> Acked-by: Bruce Richardson <bruce.richardson@intel.com>
The version python used in current FreeBSD stable release 14.3 is now 3.11. Update documentation accordingly. Signed-off-by: Stephen Hemminger <stephen@networkplumber.org> Acked-by: Bruce Richardson <bruce.richardson@intel.com>
KNI was removed from DPDK but the diagrams in the documentation were left behind. Signed-off-by: Stephen Hemminger <stephen@networkplumber.org> Acked-by: Chengwen Feng <fengchengwen@huawei.com> Acked-by: Bruce Richardson <bruce.richardson@intel.com>
This allows building and installing only the documentation, without recompiling the whole project, using: meson build -Denable_docs=true meson compile -C build doc meson install -C build --no-rebuild --tags doc In Debian/Ubuntu the documentation is built separately from the binaries, in a separate architecture-independent build job, so that it has to be done only once, instead of once per supported architecture. Signed-off-by: Luca Boccassi <bluca@debian.org> Acked-by: Bruce Richardson <bruce.richardson@intel.com>
Add tested platforms with NVIDIA NICs to the 25.11 release notes. Signed-off-by: Raslan Darawsheh <rasland@nvidia.com>
Add tested Intel platforms with Intel NICs to v25.11 release note. Signed-off-by: Yu Jiang <yux.jiang@intel.com>
Signed-off-by: Thomas Monjalon <thomas@monjalon.net>
Use device configured Rx offloads instead of hardcoded values while draining work. Fixes: e8594de ("event/cnxk: implement event port quiesce function") Cc: stable@dpdk.org Signed-off-by: Pavan Nikhilesh <pbhagavatula@marvell.com> Signed-off-by: 0-day Robot <robot@bytheb.org>
Reviewer's GuideThis PR adjusts CNXK eventdev offload flag handling and makes a series of small correctness, API‑alignment, and robustness fixes across examples, mlx5, other PMDs, and documentation/meson, including separating RX/TX burst configuration, adding eth link speed CLI options, improving flex parser configuration for new firmware, and tightening several buffer sizes and defaults. Class diagram for updated mlx5 flex parser configurationclassDiagram
class mlx5_hca_flex_attr {
+uint8_t sample_outer_ipv4
+uint8_t sample_outer_ipv6
+uint8_t sample_tunnel_inner
+uint8_t sample_tunnel_inner2
+uint8_t zero_size_supported
+uint8_t sample_id_in_out
+uint8_t header_length_field_mode_wa
+uint16_t max_base_header_length
+uint8_t max_sample_base_offset
+uint16_t max_next_header_offset
+uint8_t header_length_mask_width
}
class mlx5_devx_graph_node_attr {
+uint16_t header_length_base_value
+uint8_t header_length_field_shift
+uint16_t header_length_field_offset
+uint8_t header_length_field_offset_mode
+uint32_t header_length_field_mask
+uint16_t next_header_field_offset
}
class mlx5_devx_cmd_query_hca_parse_graph_node_cap {
+int mlx5_devx_cmd_query_hca_parse_graph_node_cap(ctx, attr)
}
class mlx5_flex_translate_length {
+int mlx5_flex_translate_length(attr, field, node, error)
}
class mlx5_devx_cmd_create_flex_parser {
+void *mlx5_devx_cmd_create_flex_parser(ctx, data)
}
mlx5_devx_cmd_query_hca_parse_graph_node_cap --> mlx5_hca_flex_attr : populates
mlx5_flex_translate_length --> mlx5_hca_flex_attr : reads
mlx5_flex_translate_length --> mlx5_devx_graph_node_attr : writes
mlx5_devx_cmd_create_flex_parser --> mlx5_devx_graph_node_attr : reads
%% New behavior relationships
mlx5_hca_flex_attr : +header_length_field_mode_wa controls offset WA
mlx5_devx_graph_node_attr : +header_length_field_offset_mode selects HW offset mode
Class diagram for l3fwd RX/TX burst usage in main loop and TX pathclassDiagram
class l3fwd_globals {
+uint32_t rx_burst_size
+uint32_t tx_burst_size
+uint16_t nb_rxd
+uint16_t nb_txd
}
class lcore_conf {
+uint16_t tx_queue_id[]
+struct tx_buffer tx_mbufs[]
}
class acl_main_loop {
+void acl_main_loop(dummy)
}
class em_main_loop {
+void em_main_loop(dummy)
}
class fib_main_loop {
+void fib_main_loop(dummy)
}
class lpm_main_loop {
+void lpm_main_loop(dummy)
}
class send_single_packet {
+void send_single_packet(qconf, mbuf, port)
}
class send_packetsx4 {
+void send_packetsx4(qconf, port, m, num)
}
l3fwd_globals <.. acl_main_loop : uses rx_burst_size
l3fwd_globals <.. em_main_loop : uses rx_burst_size
l3fwd_globals <.. fib_main_loop : uses rx_burst_size
l3fwd_globals <.. lpm_main_loop : uses rx_burst_size
l3fwd_globals <.. send_single_packet : uses rx_burst_size
l3fwd_globals <.. send_packetsx4 : uses tx_burst_size
acl_main_loop --> lcore_conf : reads queues
em_main_loop --> lcore_conf : reads queues
fib_main_loop --> lcore_conf : reads queues
lpm_main_loop --> lcore_conf : reads queues
acl_main_loop : rte_eth_rx_burst(..., rx_burst_size)
em_main_loop : rte_eth_rx_burst(..., rx_burst_size)
fib_main_loop : rte_eth_rx_burst(..., rx_burst_size)
lpm_main_loop : rte_eth_rx_burst(..., rx_burst_size)
send_single_packet : triggers send_burst when buffered == rx_burst_size
send_packetsx4 : sends directly when num >= tx_burst_size and buffer empty
Flow diagram for l3fwd parse_pkt_burst RX vs TX behaviorflowchart TD
A[Start parse_pkt_burst with optarg, is_rx_burst, burst_sz] --> B[Convert optarg to pkt_burst]
B --> C{pkt_burst > MAX_PKT_BURST?}
C -- Yes --> D[Log info: user burst must be <= MAX_PKT_BURST<br/>Using default *burst_sz]
D --> Z[End]
C -- No --> E{pkt_burst > 0?}
E -- Yes --> F[Set *burst_sz = pkt_burst]
F --> Z
E -- No, pkt_burst == 0 --> G{is_rx_burst?}
G -- Yes --> H[Query PMD via rte_eth_dev_info_get]
H --> I{ret != 0?}
I -- Yes --> Z
I -- No --> J[burst_size = dev_info.default_rxportconf.burst_size]
J --> K{burst_size == 0?}
K -- Yes --> L[Log: PMD does not recommend burst<br/>Use default rx_burst_size]
L --> Z
K -- No --> M{burst_size > MAX_PKT_BURST?}
M -- Yes --> N[Log: PMD recommended burst too large<br/>Use default rx_burst_size]
N --> Z
M -- No --> O[Set *burst_sz = burst_size<br/>Log RX burst from PMD]
O --> Z
G -- No, TX --> P[Log: TX burst is 0<br/>Use default *burst_sz]
P --> Z
File-Level Changes
Tips and commandsInteracting with Sourcery
Customizing Your ExperienceAccess your dashboard to:
Getting Help
|
WalkthroughVersion bump from rc3 to rc4, extensive documentation updates for platform compatibility and NIC models, MLX5 driver structural changes for header length field handling, CNXK driver offload mask refactoring, network driver TX packet preparation cleanup, and L3 forwarding example burst sizing refactor. Changes
Sequence Diagram(s)sequenceDiagram
participant User as L3FWD User
participant Main as main.c<br/>(parse_args)
participant Fwd as Forwarding<br/>Engine
participant PMD as PMD
User->>Main: Invoke with --rx-burst 64 --tx-burst 128
Main->>Main: Parse --rx-burst flag
Main->>Main: Call parse_pkt_burst(optarg,<br/>is_rx_burst=true,<br/>&rx_burst_size)
alt User-Provided Value
Main->>Main: Set rx_burst_size = 64
else Query PMD
Main->>PMD: Get PMD max RX burst
PMD-->>Main: Return max burst
Main->>Main: Set rx_burst_size = PMD value
end
Main->>Main: Parse --tx-burst flag
Main->>Main: Call parse_pkt_burst(optarg,<br/>is_rx_burst=false,<br/>&tx_burst_size)
alt User-Provided Value
Main->>Main: Set tx_burst_size = 128
else Query PMD
Main->>PMD: Get PMD max TX burst
PMD-->>Main: Return max burst
Main->>Main: Set tx_burst_size = PMD value
end
Main->>Fwd: Initialize forwarding with<br/>rx_burst_size, tx_burst_size
Fwd->>PMD: rte_eth_rx_burst(port, q,<br/>mbufs, rx_burst_size)
PMD-->>Fwd: Packets (≤ rx_burst_size)
Note over Fwd: Process packets
Fwd->>PMD: rte_eth_tx_burst(port, q,<br/>mbufs, len, tx_burst_size)
sequenceDiagram
participant HW as Hardware
participant DevX as DevX Layer<br/>(mlx5_prm)
participant Driver as MLX5 Driver<br/>(mlx5.c)
HW->>DevX: Report header_length_<br/>field_offset_mode
DevX->>DevX: Parse capability into<br/>mlx5_ifc_parse_graph_<br/>node_cap_bits
DevX->>Driver: Query via<br/>mlx5_devx_cmd_query_<br/>hca_parse_graph_node_cap
Driver->>Driver: Extract attr-><br/>header_length_field_mode_wa<br/>= !hw_mode_flag
Driver->>Driver: In mlx5_alloc_srh_<br/>flex_parser: check<br/>header_length_field_mode_wa
alt Workaround Enabled<br/>(legacy FW)
Driver->>Driver: offset = 8<br/>+ mask_width adjustment
else Workaround Disabled<br/>(new FW)
Driver->>Driver: offset = 12<br/>(direct)
end
Driver->>HW: Configure flex parser<br/>with computed offset
Estimated code review effort🎯 4 (Complex) | ⏱️ ~45 minutes Key areas requiring attention:
Poem
Pre-merge checks and finishing touches❌ Failed checks (1 warning)
✅ Passed checks (2 passed)
✨ Finishing touches
🧪 Generate unit tests (beta)
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. Comment |
![sourcery-ai[bot]](https://avatars.githubusercontent.com/in/48477?s=60&v=4){kind=small}
There was a problem hiding this comment.
Hey there - I've reviewed your changes - here's some feedback:
- In ip_reassembly
setup_queue_tbl(), the lcore/queue validation useslcore > RTE_MAX_LCORE || queue > RTE_MAX_QUEUES_PER_PORT, which still allows the invalid valueslcore == RTE_MAX_LCOREorqueue == RTE_MAX_QUEUES_PER_PORT; consider changing these to>=to avoid constructing overlong pool names with out-of-range IDs.
Prompt for AI Agents
Please address the comments from this code review:
## Overall Comments
- In ip_reassembly `setup_queue_tbl()`, the lcore/queue validation uses `lcore > RTE_MAX_LCORE || queue > RTE_MAX_QUEUES_PER_PORT`, which still allows the invalid values `lcore == RTE_MAX_LCORE` or `queue == RTE_MAX_QUEUES_PER_PORT`; consider changing these to `>=` to avoid constructing overlong pool names with out-of-range IDs.
## Individual Comments
### Comment 1
<location> `examples/ip_reassembly/main.c:887-892` </location>
<code_context>
nb_mbuf = RTE_MAX(nb_mbuf, (uint32_t)NB_MBUF);
+ /* 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);
</code_context>
<issue_to_address>
**suggestion (bug_risk):** Boundary checks should likely use ">=" and log message should be terminated with a newline.
To fully enforce the intended bounds, treat `RTE_MAX_LCORE` and `RTE_MAX_QUEUES_PER_PORT` as exclusive limits:
```c
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;
}
```
This prevents accepting the sentinel value (if these macros are counts rather than max indices) and adds a trailing `\n` to keep log output consistent and avoid merged log lines.
```suggestion
/* 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;
}
```
</issue_to_address>
### Comment 2
<location> `doc/guides/rel_notes/release_25_11.rst:376` </location>
<code_context>
+ * Red Hat Enterprise Linux Server release 9.6
+ * Ubuntu 24.04 LTS
+ * Ubuntu 24.04.3 LTS
+ * Vmware ESXi 8.0.3
+
+ * NICs:
</code_context>
<issue_to_address>
**nitpick (typo):** Use the standard vendor capitalization for VMware
Here, change "Vmware ESXi 8.0.3" to "VMware ESXi 8.0.3" to match the standard product name.
```suggestion
* VMware ESXi 8.0.3
```
</issue_to_address>Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 4
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (2)
examples/vdpa/main.c (1)
494-506: Add bounds check to prevent array overflow.The loop iterates over all discovered vDPA devices without verifying that
devcntstays within thevportsarray bounds. If more thanMAX_VDPA_SAMPLE_PORTS(1024) devices are present, this will cause out-of-bounds writes at lines 500-501, leading to memory corruption.Apply this diff to add a bounds check:
RTE_DEV_FOREACH(dev, "class=vdpa", &dev_iter) { + if (devcnt >= MAX_VDPA_SAMPLE_PORTS) { + RTE_LOG(WARNING, VDPA, + "Maximum number of vDPA ports (%d) reached, ignoring remaining devices\n", + MAX_VDPA_SAMPLE_PORTS); + break; + } vdev = rte_vdpa_find_device_by_name(rte_dev_name(dev)); if (vdev == NULL) { rte_panic("Failed to find vDPA dev for %s\n",doc/guides/linux_gsg/amd_platform.rst (1)
25-130: Align power note with new uncore support description.The new Uncore subsection documents
rte_power_uncoresupport from 25.03 onwards, but the preceding note still says “DPDK uncore support on Linux is work in progress,” which is now contradictory.Suggested diff to drop the outdated bullet:
.. note:: - * Power libraries are supported on Linux only. - * DPDK uncore support on Linux is work in progress. + * Power libraries are supported on Linux only.The BERGAMO|SIENA correction, TURIN guide link, and Solarflare-on-TURIN NIC guidance all look consistent.
🧹 Nitpick comments (17)
examples/server_node_efd/efd_server/main.c (1)
67-89: MAC address buffer resize correctly fixes potential overflowUsing
RTE_ETHER_ADDR_FMT_SIZE + 1foraddressesis appropriate here: the base macro covers the formatted MAC plus terminator, and the extra byte safely accommodates the explicit"\n"in thesnprintf()format. This removes the risk of a one-byte overflow while keeping the cached-per-port behavior unchanged.If you ever drop the trailing newline from the format string, you could also remove the
+ 1and leave the buffer at exactlyRTE_ETHER_ADDR_FMT_SIZEfor slightly clearer intent.examples/ip_reassembly/main.c (1)
887-892: Tighten the lcore/queue guard and make the pool-name check more robustThe new guard is a good defensive addition, but a couple of small tweaks would make it more precise and robust:
- Using
>instead of>=means values equal toRTE_MAX_LCORE/RTE_MAX_QUEUES_PER_PORTwould still be accepted, even though they’re conceptually out of range for IDs.- The log line is missing a trailing
\n, unlike most otherRTE_LOGcalls in this file.- If the real concern is name length, checking the result of
snprintfis a more direct safeguard than relying on numeric bounds.You could do something like:
- /* 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); - return -1; - } - - snprintf(buf, sizeof(buf), "mbuf_pool_%u_%u", lcore, queue); + /* Defensive 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; + } + + if (snprintf(buf, sizeof(buf), "mbuf_pool_%u_%u", lcore, queue) >= + (int)sizeof(buf)) { + RTE_LOG(ERR, IP_RSMBL, + "mbuf pool name truncated for lcore %u queue %u\n", + lcore, queue); + return -1; + }Functionally the current code is fine with existing callers; this just tightens the guard and avoids any silent name truncation.
drivers/net/cnxk/cn20k_rx.h (1)
844-853: Vector Rx locals now defensively initialized; consider narrowing scope
lbase,laddr,buf_sz, andlmt_id/d_offare now zero‑initialized, which avoids “maybe uninitialized” diagnostics and is harmless since they’re only read underNIX_RX_OFFLOAD_SECURITY_Fwhere they are set explicitly first. Optionally, you could declare these inside the security branch to tighten lifetimes, but that’s purely cosmetic.drivers/net/mlx5/mlx5_flow_flex.c (1)
575-575: Document the inverse relationship between fields.The assignment
node->header_length_field_offset_mode = !attr->header_length_field_mode_wacreates an inverse relationship between these two fields. While this appears intentional and is consistent with the query logic inmlx5_devx_cmds.c(line 916-917), the relationship is not immediately obvious from the field names.Consider adding a comment explaining this inverse relationship:
node->header_length_field_offset = offset; + /* offset_mode is the inverse of the workaround flag */ node->header_length_field_offset_mode = !attr->header_length_field_mode_wa;drivers/common/mlx5/mlx5_devx_cmds.h (2)
122-122: Add documentation for the new capability field.The new
header_length_field_mode_wabitfield lacks documentation explaining its purpose. The "wa" suffix likely means "workaround," but this should be explicitly documented for maintainability.Consider adding a comment:
uint8_t sample_id_in_out:1; + /* Workaround flag: true if hardware requires workaround for header length field mode */ uint8_t header_length_field_mode_wa:1; uint16_t max_base_header_length;
652-652: Add documentation for the new configuration field.The
header_length_field_offset_modebitfield should be documented to explain its purpose and relationship toheader_length_field_mode_wa. This would improve code maintainability and clarify the inverse relationship between these fields.Consider adding a comment:
uint32_t header_length_field_offset:16; + /* Offset mode: inverse of workaround flag, written to hardware */ uint32_t header_length_field_offset_mode:1; uint32_t header_length_field_mask;drivers/common/mlx5/mlx5_prm.h (1)
2110-2132: Newheader_length_field_offset_modecapability bit preserves layoutThe split of
reserved_at_78[0x3]intoreserved_at_78[0x1],header_length_field_offset_mode[0x1], andreserved_at_79[0x1]keeps the total at 3 bits, so the overall bit layout ofmlx5_ifc_parse_graph_node_cap_bitsis unchanged while adding the new capability. Consider adding an enum or brief comment describing valid values for this mode to aid future readers.examples/l3fwd-power/main.c (1)
1746-1747:--eth-link-speedparsing looks correct; consider tightening invalid-input handlingThe new option wiring (macro, long option entry, local
speed_num, and the handler) is consistent and correctly updatesport_conf.link_speedsusingrte_eth_speed_bitflag(), with explicit rejection of 10M and 100M.Two minor refinements you may want to consider:
- Cache
rte_eth_speed_bitflag(speed_num, 0)in a local and reuse it instead of calling twice.- Today, non-numeric or unsupported speeds (where
rte_eth_speed_bitflag()returns 0) are silently ignored. If you want stricter UX, you could treat that as an error and print a short message beforeprint_usage()andreturn -1, similar to the 10M/100M case.Functionally fine as-is; these are optional cleanups.
Also applies to: 1753-1753, 1773-1773, 1958-1970
examples/l3fwd/l3fwd_acl.c (1)
1138-1141: RX burst sizing correctly hooked torx_burst_size; ensure it’s boundedSwitching
rte_eth_rx_burst()to userx_burst_sizealigns this loop with the new configurable RX burst behavior and matches thepkts_burst[MAX_PKT_BURST]capacity, assuming:
rx_burst_size > 0, andrx_burst_size <= MAX_PKT_BURST.Please double-check that the CLI parsing for
--rx-burstenforces these bounds so we never overrun thepkts_burstandhopsarrays.examples/l3fwd/l3fwd_fib.c (1)
239-243: Configurable RX burst applied here as well; rely on global boundsUsing
rx_burst_sizeforrte_eth_rx_burst()keeps the FIB main loop consistent with the new per-direction burst configuration. As with other loops, this is safe as long asrx_burst_sizeis validated to be within[1, MAX_PKT_BURST]during option parsing.examples/l3fwd/l3fwd_lpm.c (1)
204-210: LPM RX loop now honors--rx-burst; confirm max-burst constraintsThe LPM main loop now uses
rx_burst_sizefor RX, which is consistent with the rest of the refactor. Please ensure the globalrx_burst_sizeis never configured aboveMAX_PKT_BURSTso thepkts_burst[MAX_PKT_BURST]buffer cannot be overrun.examples/l3fwd/l3fwd_em.c (1)
643-648: Exact-match RX path usesrx_burst_size; same bounding requirementThe EM main loop’s RX burst size now follows
rx_burst_size, consistent with the other lookup modes. As with them, this assumesrx_burst_sizeis clamped to1..MAX_PKT_BURSTat configuration time to avoid overrunningpkts_burst.examples/l3fwd/l3fwd_common.h (1)
28-30:tx_burst_sizeintegration intosend_packetsx4looks good; just ensure sane boundsSwitching the early-send condition to:
if (num >= tx_burst_size && len == 0) { n = rte_eth_tx_burst(port, qconf->tx_queue_id[port], m, num); ... }is consistent with the new per-direction TX burst tuning and keeps the buffered path limited by
MAX_PKT_BURST.Two points to keep in mind:
- Make sure
tx_burst_sizeis initialized to a sensible default (e.g., 32) and validated to1 <= tx_burst_size <= MAX_PKT_BURSTin the CLI parsing, so this fast path doesn’t become a no-op (too large) or overly aggressive (too small/zero).- Once
send_single_packet()is updated to usetx_burst_sizeas well, both TX paths will behave consistently with the documented--tx-burstoption.Otherwise, this change is sound.
Also applies to: 66-85
doc/guides/sample_app_ug/l3_forward.rst (1)
80-82: New--rx-burst/--tx-burstdocumentation aligns with code changesThe added options in the usage synopsis and the detailed bullets match the new per-direction burst variables and defaults (32), and clearly distinguish RX vs TX behavior.
If you later clamp these values in code (e.g., to
MAX_PKT_BURST), it might be worth briefly mentioning the effective range here, but that’s optional polish.Also applies to: 118-121
examples/l3fwd/main.c (2)
703-751: parse_pkt_burst refactor is correct; consider clarifying/aligning TX=0 behaviorThe refactored
parse_pkt_burst(const char *optarg, bool is_rx_burst, uint32_t *burst_sz)keeps previous semantics for valid values and caps atMAX_PKT_BURST. RX-specific handling of0(querying PMD and validating against[1, MAX_PKT_BURST]) is sound, and using*burst_szas the “default” in log messages is consistent.Two potential follow‑ups:
- For TX,
pkt_burst == 0is now just “log and keep default”. If the PMD exposes a recommended TX burst, you might want to mirror the RX path (query and clamp) for symmetry, or at least document in the help that0has special meaning only for RX.rte_eth_dev_info_get(0, ...)assumes port 0 as the reference; if recommended burst sizes can differ across ports, consider either documenting that assumption or, longer‑term, deferring PMD‑based tuning until ports are known and picking a representative enabled port.These are incremental improvements; current behavior is consistent and safe.
881-882: eth-link-speed parsing works but is less strict than other optionsThe new
CMD_LINK_OPT_ETH_LINK_SPEED_NUMbranch correctly setsport_conf.link_speedsviarte_eth_speed_bitflag()and explicitly rejects 10M/100M speeds, which matches the stated “unsupported fixed speed” policy. RX/TX burst options are properly routed toparse_pkt_burst()with the right direction flag.Compared to other parsers in this file (
parse_queue_size,parse_pkt_burst), theeth-link-speedbranch is relatively permissive:
- It uses
atoi()without checking for invalid input, so values like"abc"or"1G"silently result in no configuration change (speed remains default) with no warning.- Negative or otherwise unmappable numeric values are likewise ignored.
If you want behavior consistent with the rest of the CLI, consider:
- Switching to
strtol()and validating the full string was consumed.- Treating invalid or unsupported values as an error (or at least emitting a warning) rather than silently ignoring them, so users know their
--eth-link-speedrequest was not applied.Burst parsing itself is aligned with the new per‑direction global variables.
Also applies to: 930-940, 949-955
doc/guides/windows_gsg/build_dpdk.rst (1)
28-147: Windows build guidance improvements look good; consider HTTPS for Meson link.The LLVM/MinGW updates and the explicit Visual Studio Developer Command Prompt example plus PowerShell note make the build instructions clearer.
One small consistency tweak: the Meson link still uses HTTP while everything else here is HTTPS; Meson also supports HTTPS.
Suggested doc change:
-Download and install the build system from -`Meson website <http://mesonbuild.com/Getting-meson.html>`_. +Download and install the build system from +`Meson website <https://mesonbuild.com/Getting-meson.html>`_.Please confirm that the HTTPS URL variant is valid for your docs toolchain.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
⛔ Files ignored due to path filters (2)
doc/guides/prog_guide/img/kni_traffic_flow.pngis excluded by!**/*.pngdoc/guides/prog_guide/img/pkt_flow_kni.pngis excluded by!**/*.png
📒 Files selected for processing (42)
VERSION(1 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(1 hunks)doc/guides/sample_app_ug/l3_forward.rst(2 hunks)doc/guides/windows_gsg/build_dpdk.rst(4 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/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/hns3/hns3_rxtx.c(2 hunks)drivers/net/mlx5/mlx5.c(2 hunks)drivers/net/mlx5/mlx5_flow_flex.c(2 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/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/ntnic/ntnic_ethdev.c
- drivers/net/softnic/rte_eth_softnic.c
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (1)
- GitHub Check: Sourcery review
🔇 Additional comments (44)
doc/guides/freebsd_gsg/build_dpdk.rst (2)
19-19: Package version update is correct.The change from
py38-pyelftoolstopy311-pyelftoolsproperly reflects the Python 3.11 requirement and aligns with the updated note.
28-28: Installation command update is consistent.The command correctly reflects the updated
py311-pyelftoolspackage name and aligns with the prerequisite list changes.drivers/event/cnxk/cn20k_eventdev.c (3)
195-195: LGTM! Offload flags correctly applied during event flush.The change from a static
0todev->rx_offloadsensures that work retrieval during queue flush respects the device's configured RX offload flags. This prevents incorrect packet processing during flush operations.
524-524: LGTM! Offload flags correctly applied during port quiesce.Using
dev->rx_offloadsinstead of a static0ensures that pending work extraction during port quiesce operations respects the device's configured RX offload flags.
550-550: LGTM! Offload flags correctly applied for prefetch queue work.The change ensures that work extraction from the prefetch queue (PRF_WQE0) also respects the device's configured RX offload flags, maintaining consistency across all work retrieval paths.
drivers/event/cnxk/cn10k_eventdev.c (3)
129-129: LGTM! Offload flags correctly applied during event flush.The change from a static maximum offload mask to
dev->rx_offloadsensures that work retrieval during queue flush uses only the device's actually configured RX offload flags, preventing unnecessary processing overhead and potential incorrect behavior.
475-475: LGTM! Offload flags correctly applied during port quiesce.Using
dev->rx_offloadsinstead of a static mask ensures that pending work extraction during port quiesce operations correctly applies only the device's configured RX offload flags.
504-504: LGTM! Offload flags correctly applied for prefetch queue work.The change ensures that work extraction from the prefetch queue (PRF_WQE0) respects the device's configured RX offload flags, completing the consistent offload handling across all work retrieval paths in both cn10k and cn20k drivers.
drivers/event/cnxk/cn20k_worker.h (1)
57-59: LGTM! Defensive initialization improves code safety.The explicit initialization of
meta_aura,laddr,lmt_id, andd_offto zero is good defensive programming practice. While the existing logic ensures these variables are set before use within their respective code paths (security offload blocks), the initializations eliminate any risk of undefined behavior and improve code clarity.drivers/event/cnxk/cn10k_worker.h (1)
55-58: LGTM! Consistent defensive initialization.The initialization of
meta_aura,laddr,lmt_id,d_offto zero andmpto NULL follows the same defensive programming pattern as the cn20k implementation. Initializing the pointermpto NULL is particularly important for preventing potential null pointer dereferences. These changes improve code safety without altering functionality.examples/server_node_efd/shared/common.h (1)
61-63: Perfect. Now I have a complete understanding of the code. Let me generate the final rewritten review comment:
Using
RTE_RING_NAMESIZEis correct and properly defined at compile time.The refactor to use
RTE_RING_NAMESIZEinstead of a calculated buffer size is good practice. Verification confirms that all translation units that actually instantiateget_rx_queue_name()(main.c, node.c, init.c) include<rte_ring.h>before includingcommon.h, ensuringRTE_RING_NAMESIZEis defined when needed. The inline function pattern isolates the constant dependency to actual call sites, and files likeargs.cthat includecommon.hwithout using the function are unaffected. No changes required.examples/vdpa/main.c (3)
25-25: Buffer overflow prevention fix is correct.The reduction in
ifacebuffer size correctly accounts for the space needed when concatenating withdevcntat line 501. The calculationMAX_PATH_LEN - MAX_VDPA_STR_LEN(128 - 5 = 123 bytes) ensures thatiface(max 122 chars) plus the maximumdevcntvalue "1023" (4 chars) plus null terminator fits within the 128-byteifnamedestination.Also applies to: 40-40
78-78: Correct fix: usestrcmpfor option name comparison.Replacing
strncmpwithstrcmpis appropriate for comparing the exact option name. UsingMAX_PATH_LENas the comparison length was incorrect sincelong_option[idx].nameis the option string "iface", not a path.
79-79: Correct use ofsizeof(iface)for buffer safety.Using
sizeof(iface)instead of the hardcodedMAX_PATH_LENcorrectly reflects the actual buffer size and improves maintainability.drivers/net/cnxk/cn20k_rx.h (1)
304-312: Zero-initializingfsz_w1/cq_w5removes undefined-value riskInitializing
fsz_w1andcq_w5to 0 is safe (they are still overwritten on the active paths) and prevents any potential use of indeterminate values if control flow changes later. No behavioral change, just safer defaults.drivers/net/cnxk/cn10k_rx.h (2)
568-578: Initializeinb_privdefensively innix_sec_meta_to_mbufSetting
inb_priv = NULLat declaration is a safe defensive change; actual uses still occur only wheninb_sais valid, but this removes any chance of reading an indeterminate pointer if logic is extended later.
1463-1472: Vector Rx security-path locals now initialized to known valuesThe zero‑initialization of
lmt_id,d_off,lbase, andladdris harmless (they are assigned before use when security offload is enabled) and resolves potential compiler warnings about uninitialized reads. No behavior change from previous logic.drivers/net/ngbe/ngbe_rxtx.c (1)
1918-1945: Use dummytx_pkt_preparein simple Tx path for consistent API surfaceAssigning
dev->tx_pkt_prepare = rte_eth_tx_pkt_prepare_dummyin the simple (no‑offload) path keeps the driver’stx_pkt_preparecallback valid in all modes and matches the pattern in other PMDs; behavior remains a no‑op for simple Tx.If you want to double‑check against your DPDK version, please confirm that
rte_eth_tx_pkt_prepare_dummyis the recommended placeholder for PMDs that don’t need per‑packet prep in the simple path.drivers/net/txgbe/txgbe_rxtx.c (1)
2341-2350: Simple TX path now exposes a safe, non-NULLtx_pkt_preparecallbackSetting
dev->tx_pkt_prepare = rte_eth_tx_pkt_prepare_dummyin the simple path aligns this PMD with the full-featured path and other drivers: callers can always rely on a valid prepare callback, and using the dummy implementation is correct when offloads are disabled in this path.drivers/net/hns3/hns3_rxtx.c (2)
4558-4565: Non-started / reset path now uses dummytx_pkt_prepareinstead of NULLUsing
rte_eth_tx_pkt_prepare_dummywhen the device is not started (and TX is already routed torte_eth_pkt_burst_dummy) keepstx_pkt_preparenon-NULL and consistent with the started path behavior, without changing effective datapath behavior.
4917-4922: Stopping TX datapath now also clearstx_pkt_prepareto the dummy helperWhen TX is stopped, both
tx_pkt_burstandtx_pkt_prepareare now set to their dummy implementations, which avoids dangling or NULL callbacks on both primary and secondary processes and matches howhns3_set_rxtx_function()initializes these hooks.drivers/common/mlx5/mlx5_devx_cmds.c (2)
787-788: LGTM! Field initialization added correctly.The initialization of
header_length_field_offset_modefrom the input data structure is properly integrated into the flex parser creation command.
916-917: LGTM! Hardware capability query correctly derives workaround flag.The derivation of
header_length_field_mode_waas the negation of the hardware'sheader_length_field_offset_modecapability is logically consistent with how it's used throughout the codebase. This correctly identifies hardware that requires the workaround.drivers/net/mlx5/mlx5_flow_flex.c (1)
557-570: Based on my verification, I have a complete picture of how this feature is implemented. The concerns raised in the original review are actually already addressed in the codebase.No backward compatibility issues found. The gating condition is properly designed.
The
header_length_field_mode_waflag is:
Automatically initialized from hardware capabilities (mlx5_devx_cmds.c:916):
- Set to
!MLX5_GET(parse_graph_node_cap, hcattr, header_length_field_offset_mode)- Queries the device and inverts the offset_mode bit
- Applies to all hardware versions that report parse_graph capabilities
Firmware-dependent (as documented in mlx5.c:1084):
truefor legacy firmware before ConnectX-8 → uses workaround logicfalsefor new firmware (ConnectX-8+) → skips workaround, uses native offset_mode supportIntentionally dual-pathed:
- Both code paths are maintained and explicitly handled
- No breaking changes—older hardware still gets the workaround, newer hardware uses native support
- This is a well-designed compatibility solution, not a regression
The code already has clear comments explaining the workaround and when it applies. No additional initialization checks or comments are needed.
drivers/net/mlx5/mlx5.c (2)
1083-1091: SRH flex parser header-length offset gating looks correctThe split between legacy
header_length_field_mode_wahandling and the direct offset path for new firmware is clear and keeps the existing WA logic intact while simplifying the non-WA case. No functional issues spotted in the offset computation.
1494-1497: Defaultdv_flow_en=1andallow_duplicate_pattern=1behaviorThe new defaults (enable DV flow steering and allow duplicate pattern by default, with later capability-based downgrading) are consistent with the updated documentation and existing capability checks (
sh->dev_cap.dv_flow_en,dev_cap.dv_esw_en). This looks fine from a behavior and compatibility standpoint.doc/guides/nics/mlx5.rst (2)
699-701: Defaults fordv_flow_enandallow_duplicate_patternare clearly documented and match codeDocumenting that
dv_flow_endefaults to 1 (DV steering) when supported and 0 otherwise, and thatallow_duplicate_patterndefaults to 1, aligns with the implementation inmlx5_shared_dev_ctx_args_config(). This makes the behavioral change explicit for users relying on implicit defaults.Also applies to: 836-837
650-651: HWS + synchronous flow API limitations and requirements are well captured; please double‑check version detailsThe new notes tying together HWS behavior with the synchronous API (tunnel-offload restriction in
dv_xmeta_en=3, need to callrte_flow_configure()before async flows, match-field size limits vs SWS, update semantics, defaultrte_flow_port_attr/queue/action allocation, partial-mask behavior, representor/transfer constraints, MARK vs META support, GREc_rsvd0_verlimitation in group 0, and COUNT/AGE support on root tables plus their minimum kernel/rdma-core/DOCA versions) give a much clearer picture of what applications can rely on whendv_flow_en=2.From a docs perspective this is coherent and consistent with the rest of the guide; I don’t see contradictions with the described flow engines. Given the explicit external version constraints for COUNT/AGE-on-root support, it would be good to re-verify those minimum kernel/rdma-core/DOCA numbers against the current releases before merging.
Also applies to: 1366-1372, 1410-1444, 2396-2403, 2593-2596, 2754-2763, 2813-2823, 3817-3821
drivers/common/mlx5/mlx5_prm.h (3)
1600-1602: Steering logic format macros look consistent and non-breakingSwitching to
#define MLX5_STEERING_LOGIC_FORMAT_*constants with values0x0and0x1matches the 4‑bitsteering_format_versionfield and should be ABI‑safe; no issues from this header’s perspective.
2351-2357: Expandedreserved_at_0in ESW flow table caps should be double‑checked against PRMWidening
reserved_at_0to[0x800]inmlx5_ifc_flow_table_esw_cap_bitsshifts subsequent fields but keeps the struct internally consistent. Assuming this matches the updated PRM layout, it looks fine; just ensure any code that relies on hard‑coded offsets into this capability block has been aligned with the new definition.
4979-4999: Flex‑parser header length offset mode bit is structurally correctIntroducing
header_length_field_offset_mode[0x1]by splitting the previous 3‑bitreserved_at_178intoreserved_at_178[0x1], the new mode bit, andreserved_at_17a[0x1]preserves total width and maintains the rest ofmlx5_ifc_parse_graph_flex_bitsunchanged; layout remains compatible while exposing the new feature.examples/l3fwd-power/main.c (1)
1490-1507: Help text for--eth-link-speedis consistent and clearThe new usage line documents the option name and behavior consistently with the macro and parser. No issues here.
examples/l3fwd/main.c (4)
57-62: Compile-time cache/burst relationship and separate RX/TX burst globals look goodThe
static_assertcorrectly enforcesMEMPOOL_CACHE_SIZE >= MAX_PKT_BURST, and the newrx_burst_size/tx_burst_sizeglobals are sensibly defaulted toDEFAULT_PKT_BURSTfor later tuning. No functional issues here.
404-405: CLI help text matches new options and format arguments are consistentThe added
--rx-burst,--tx-burst, and--eth-link-speedusage lines align with the implemented options, and the additional%dplaceholders for RX/TX burst defaults are correctly wired to the twoDEFAULT_PKT_BURSTarguments. This keeps the help output in sync with the behavior.Also applies to: 428-429, 433-435, 468-469
762-763: New long-option constants and lgopts wiring are coherent
CMD_LINK_OPT_ETH_LINK_SPEED,CMD_LINE_OPT_PKT_RX_BURST, andCMD_LINE_OPT_PKT_TX_BURSTare correctly added to the enum range, andlgopts[]entries map them to the right numeric codes. This keeps getopt handling centralized and avoids collisions with existing options.Also applies to: 784-785, 795-796, 817-818, 822-825, 847-848
1690-1691: Burst-size logging is a useful additionLogging
rx_burst_sizeandtx_burst_sizeafter argument parsing provides clear visibility into the effective burst settings (including any PMD‑driven RX adjustment) at startup, which should help debugging and benchmarking runs.VERSION (1)
1-1: Version bump to 25.11.0-rc4 looks consistent.Single-source version string update, in line with the 25.11 release docs in this PR and with no behavioral impact.
doc/guides/cryptodevs/ionic.rst (1)
2-20: Ionic crypto model list and copyright update look good.The new Pollara 400 entry matches the existing bullet/list formatting and link style, and the extended 2021‑2025 copyright range is consistent with current year coverage.
examples/meson.build (1)
81-83: Resettingdefault_cflagstomachine_argsis reasonable; watch for new warnings.Removing any extra flags (such as
-Wno-format-truncationif that was present before) will re-expose compiler diagnostics in example builds. This is fine as long as all examples build cleanly across supported compilers with your warning/error policy.If not already done, please ensure
-Dexamples=allbuilds pass on at least GCC and Clang with your default warning settings.doc/guides/nics/i40e.rst (1)
107-142: 25.11 i40e kernel/FW mapping entries are consistent.The added 25.11 rows follow the existing table format, keep the version ordering intact, and match the driver/firmware combinations documented in the 25.11 Tested Platforms section of the release notes.
doc/guides/nics/ice.rst (1)
90-101: New 25.11 ICE compatibility rows look correct.The added 25.11 mappings for E810 and E830 maintain table ordering and are consistent with the DDP and firmware versions listed for those SKUs in the 25.11 release notes.
doc/guides/nics/ionic.rst (2)
2-2: LGTM!The copyright year update is appropriate for the 2025 release.
18-19: The Pollara 400 entry is properly formatted and consistent with existing entries, but external URL verification cannot be completed in the sandbox environment.The new entry at lines 18-19 follows the exact same formatting pattern as the other AMD Pensando product briefs (Elba at line 15 and DSC3-400 at line 17). The reStructuredText syntax is correct. However, due to sandbox network restrictions, I cannot verify that the PDF URL is actually accessible. This requires manual verification by visiting the URL directly or testing from an environment with unrestricted internet access.
The URL structure follows the same domain and path pattern as the other working product brief links, which is a positive indicator.
doc/api/meson.build (1)
30-30: LGTM! Consistent documentation tagging.The addition of
install_tag: 'doc'to all three documentation targets (examples.dox, doxygen-html, doxygen-man) is consistent and follows the same pattern as the changes indoc/guides/meson.build. This enables unified selective installation of documentation artifacts.Note: As mentioned in the review for
doc/guides/meson.build, please verify that the project's minimum Meson version is 0.60.0 or later to support theinstall_tagparameter.Also applies to: 80-80, 95-95
| .. note:: | ||
|
|
||
| The specific package for pyelftools is dependent on the version of python in use, | ||
| Python 3.8 being the version at type of writing, hence the ``py38`` prefix. | ||
| The specific package for pyelftools is dependent on the version of python in use, | ||
| Python 3.11 being the version at type of writing, hence the ``py311`` prefix. |
There was a problem hiding this comment.
Fix typo in documentation note.
Line 24 contains a grammatical error: "at type of writing" should be "at time of writing".
Apply this diff to fix the typo:
The specific package for pyelftools is dependent on the version of python in use,
- Python 3.11 being the version at type of writing, hence the ``py311`` prefix.
+ Python 3.11 being the version at time of writing, hence the ``py311`` prefix.📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| .. note:: | |
| The specific package for pyelftools is dependent on the version of python in use, | |
| Python 3.8 being the version at type of writing, hence the ``py38`` prefix. | |
| The specific package for pyelftools is dependent on the version of python in use, | |
| Python 3.11 being the version at type of writing, hence the ``py311`` prefix. | |
| .. note:: | |
| The specific package for pyelftools is dependent on the version of python in use, | |
| Python 3.11 being the version at time of writing, hence the ``py311`` prefix. |
🤖 Prompt for AI Agents
In doc/guides/freebsd_gsg/build_dpdk.rst around lines 21 to 24, the
documentation note contains a typo: replace the phrase "at type of writing" with
"at time of writing" so the sentence reads that Python 3.11 was the version at
time of writing; update the text accordingly.
| depfile: '.html.d', | ||
| build_by_default: get_option('enable_docs'), | ||
| install: get_option('enable_docs'), | ||
| install_tag: 'doc', |
There was a problem hiding this comment.
🧩 Analysis chain
Script executed:
#!/bin/bash
# Check minimum required Meson version in the project
echo "=== Searching for Meson version requirements ==="
rg -n "meson_version|project\(" --type python meson.build | head -30Repository: ovsrobot/dpdk
<shell_result>
Repository: ovsrobot/dpdk
Script execution failed with error: Request timed out after 120000ms (requestId=e5d6d7a5-90f0-42c0-9fe9-9d1be4198559)
</shell_result>
Script executed:
#!/bin/bash
# Check the root meson.build for version requirements
echo "=== Checking root meson.build ==="
head -50 meson.build 2>/dev/null || echo "Root meson.build not found"
# Also check if there's version info in the doc/guides directory
echo ""
echo "=== Checking doc/guides/meson.build ==="
head -30 doc/guides/meson.build 2>/dev/null || echo "File not found"Repository: ovsrobot/dpdk
<shell_result>
Repository: ovsrobot/dpdk
Exit code: 0
stdout:
=== Checking root meson.build ===
# SPDX-License-Identifier: BSD-3-Clause
# Copyright(c) 2017-2019 Intel Corporation
project('DPDK', 'c',
version: files('VERSION'),
license: 'BSD',
default_options: [
'buildtype=release',
'c_std=c11',
'default_library=static',
'warning_level=2',
],
meson_version: '>= 0.57.2'
# meson_version_windows: '>= 1.5.2'
)
fs = import('fs')
# check for developer mode
developer_mode = false
if get_option('developer_mode').auto()
developer_mode = fs.exists('.git')
else
developer_mode = get_option('developer_mode').enabled()
endif
if developer_mode
message('## Building in Developer Mode ##')
endif
# set up some global vars for compiler, platform, configuration, etc.
cc = meson.get_compiler('c')
dpdk_source_root = meson.current_source_dir()
dpdk_build_root = meson.current_build_dir()
dpdk_conf = configuration_data()
dpdk_includes = []
dpdk_libraries = []
dpdk_static_libraries = []
dpdk_shared_lib_deps = []
dpdk_static_lib_deps = []
dpdk_arch_headers = []
dpdk_arch_indirect_headers = []
dpdk_generic_headers = []
dpdk_headers = []
dpdk_indirect_headers = []
dpdk_drivers_headers = []
dpdk_driver_classes = []
dpdk_drivers = []
dpdk_extra_ldflags = []
dpdk_libs_deprecated = []
dpdk_apps_disabled = []
=== Checking doc/guides/meson.build ===
# SPDX-License-Identifier: BSD-3-Clause
# Copyright(c) 2018 Intel Corporation
sphinx = find_program('sphinx-build', required: get_option('enable_docs'))
if not sphinx.found()
subdir_done()
endif
extra_sphinx_args = ['-a']
if get_option('werror')
extra_sphinx_args += '-W'
endif
htmldir = join_paths(get_option('datadir'), 'doc', 'dpdk', 'guides')
html_guides = custom_target('html_guides',
input: files('index.rst'),
output: 'html',
command: [sphinx_wrapper, sphinx, meson.project_version(),
meson.current_source_dir(), meson.current_build_dir(),
extra_sphinx_args],
depfile: '.html.d',
build_by_default: get_option('enable_docs'),
install: get_option('enable_docs'),
install_tag: 'doc',
install_dir: htmldir)
doc_targets += html_guides
doc_target_names += 'HTML_Guides'
</shell_result>
Based on my verification, I've found a compatibility issue with the added install_tag parameter.
The project's root meson.build specifies meson_version: '>= 0.57.2', but the install_tag parameter requires Meson 0.60.0 or later. The minimum version requirement (0.57.2) does not meet the feature requirement (0.60.0).
Update minimum Meson version requirement to support install_tag parameter.
The addition of install_tag: 'doc' requires Meson version 0.60.0 or later. The project's current minimum version is 0.57.2. Either update the minimum Meson version in meson.build to >= 0.60.0, or remove the install_tag parameter from the custom_target.
🤖 Prompt for AI Agents
In doc/guides/meson.build around line 25, the custom_target uses install_tag
which requires Meson >= 0.60.0 while the project declares meson_version: '>=
0.57.2'; update the meson_version in the root meson.build to '>= 0.60.0' to
match the new feature, or alternatively remove the install_tag: 'doc' parameter
from this custom_target so it remains compatible with the existing minimum
version.
| * Intel\ |reg| platforms with Intel\ |reg| NICs combinations | ||
|
|
||
| * CPU | ||
|
|
||
| * Intel\ |reg| Atom\ |trade| x7835RE | ||
| * Intel\ |reg| Xeon\ |reg| 6553P-B CPU @ 2.6GHz | ||
| * Intel\ |reg| Xeon\ |reg| 6767P CPU @ 2.4GHz | ||
| * Intel\ |reg| Xeon\ |reg| CPU Max 9480 | ||
| * Intel\ |reg| Xeon\ |reg| CPU Max 9480 CPU @ 1.9GHz | ||
| * Intel\ |reg| Xeon\ |reg| Gold 6330 CPU @ 2.00GHz | ||
| * Intel\ |reg| Xeon\ |reg| Gold 6348 CPU @ 2.60GHz | ||
| * Intel\ |reg| Xeon\ |reg| Platinum 8280M CPU @ 2.70GHz | ||
| * Intel\ |reg| Xeon\ |reg| Platinum 8380 CPU @ 2.30GHz | ||
| * Intel\ |reg| Xeon\ |reg| Platinum 8468H CPU @ 2.1GHz | ||
| * Intel\ |reg| Xeon\ |reg| Platinum 8490H CPU @ 1.9GHz | ||
|
|
||
| * OS: | ||
|
|
||
| * Fedora 42 | ||
| * FreeBSD 14.3 | ||
| * Microsoft Azure Linux 3.0 | ||
| * OpenAnolis OS 8.10 | ||
| * openEuler 24.03 (LTS-SP2) | ||
| * Red Hat Enterprise Linux Server release 10 | ||
| * Red Hat Enterprise Linux Server release 9.6 | ||
| * Ubuntu 24.04 LTS | ||
| * Ubuntu 24.04.3 LTS | ||
| * Vmware ESXi 8.0.3 | ||
|
|
||
| * NICs: | ||
|
|
||
| * Intel\ |reg| Ethernet Controller E810-C for SFP (4x25G) | ||
|
|
||
| * Firmware version: 4.90 0x80020eeb 1.3863.0 | ||
| * Device ID (PF/VF): 8086:1593 / 8086:1889 | ||
| * Driver version (out-of-tree): 2.3.14 (ice) | ||
| * Driver version (in-tree): 6.8.0-86-generic (Ubuntu24.04 LTS) (ice) | ||
| * OS Default DDP: 1.3.43.0 | ||
| * COMMS DDP: 1.3.55.0 | ||
| * Wireless Edge DDP: 1.3.25.0 | ||
|
|
||
| * Intel\ |reg| Ethernet Controller E810-C for QSFP (2x100G) | ||
|
|
||
| * Firmware version: 4.90 0x80020ef2 1.3863.0 | ||
| * Device ID (PF/VF): 8086:1592 / 8086:1889 | ||
| * Driver version (out-of-tree): 2.3.14 (ice) | ||
| * Driver version (in-tree): 6.6.12.1-1.azl3+ice+ (Microsoft Azure Linux 3.0) / | ||
| 6.12.0-55.9.1.el10_0.x86_64+rt (RHEL10) (ice) | ||
| * OS Default DDP: 1.3.43.0 | ||
| * COMMS DDP: 1.3.55.0 | ||
| * Wireless Edge DDP: 1.3.25.0 | ||
|
|
||
| * Intel\ |reg| Ethernet Controller E830-CC for SFP | ||
|
|
||
| * Firmware version: 1.20 0x800179c0 1.3862.0 | ||
| * Device ID (PF/VF): 8086:12d3 / 8086:1889 | ||
| * Driver version: 2.3.14 (ice) | ||
| * OS Default DDP: 1.3.43.0 | ||
| * COMMS DDP: 1.3.55.0 | ||
| * Wireless Edge DDP: 1.3.25.0 | ||
|
|
||
| * Intel\ |reg| Ethernet Controller E830-CC for QSFP | ||
|
|
||
| * Firmware version: 1.20 0x800179c1 1.3862.0 | ||
| * Device ID (PF/VF): 8086:12d2 / 8086:1889 | ||
| * Driver version: 2.3.14 (ice) | ||
| * OS Default DDP: 1.3.43.0 | ||
| * COMMS DDP: 1.3.55.0 | ||
| * Wireless Edge DDP: 1.3.25.0 | ||
|
|
||
| * Intel\ |reg| Ethernet Connection E825-C for QSFP | ||
|
|
||
| * Firmware version: 4.04 0x80007e5c 1.3885.0 | ||
| * Device ID (PF/VF): 8086:579d / 8086:1889 | ||
| * Driver version: 2.3.14 (ice) | ||
| * OS Default DDP: 1.3.43.0 | ||
| * COMMS DDP: 1.3.55.0 | ||
| * Wireless Edge DDP: 1.3.25.0 | ||
|
|
||
| * Intel\ |reg| Ethernet Network Adapter E610-XT2 | ||
|
|
||
| * Firmware version: 1.30 0x8000e8a2 1.3864.0 | ||
| * Device ID (PF/VF): 8086:57b0 / 8086:57ad | ||
| * Driver version (out-of-tree): 6.2.5 (ixgbe) | ||
|
|
||
| * Intel\ |reg| Ethernet Network Adapter E610-XT4 | ||
|
|
||
| * Firmware version: 1.30 0x8000e8a5 1.3864.0 | ||
| * Device ID (PF/VF): 8086:57b0 / 8086:57ad | ||
| * Driver version (out-of-tree): 6.2.5 (ixgbe) | ||
|
|
||
| * Intel\ |reg| Ethernet Converged Network Adapter X710-DA4 (4x10G) | ||
|
|
||
| * Firmware version: 9.55 0x8000fdf4 1.3862.0 | ||
| * Device ID (PF/VF): 8086:1572 / 8086:154c | ||
| * Driver version (in-tree): 6.8.0-88-generic (i40e) | ||
|
|
||
| * Intel\ |reg| Corporation Ethernet Connection X722 for 10GbE SFP+ (2x10G) | ||
|
|
||
| * Firmware version: 6.51 0x80004430 1.3862.0 | ||
| * Device ID (PF/VF): 8086:37d0 / 8086:37cd | ||
| * Driver version (out-of-tree): 2.28.13 (i40e) | ||
|
|
||
| * Intel\ |reg| Ethernet Converged Network Adapter XXV710-DA2 (2x25G) | ||
|
|
||
| * Firmware version: 9.55 0x8000fe4c 1.3862.0 | ||
| * Device ID (PF/VF): 8086:158b / 8086:154c | ||
| * Driver version (out-of-tree): 2.28.13 (i40e) | ||
| * Driver version (in-tree): 6.8.0-88-generic (Ubuntu24.04.3 LTS) / | ||
| 6.12.0-55.9.1.el10_0.x86_64 (RHEL10) (i40e) | ||
|
|
||
| * Intel\ |reg| Ethernet Converged Network Adapter XL710-QDA2 (2X40G) | ||
|
|
||
| * Firmware version(PF): 9.55 0x8000fe31 1.3862.0 | ||
| * Device ID (PF/VF): 8086:1583 / 8086:154c | ||
| * Driver version (out-of-tree): 2.28.13 (i40e) | ||
|
|
||
| * Intel\ |reg| Ethernet Controller I226-LM | ||
|
|
||
| * Firmware version: 2.14, 0x8000028c | ||
| * Device ID (PF): 8086:125b | ||
| * Driver version (in-tree): 6.8.0-87-generic (Ubuntu24.04.3 LTS) (igc) | ||
|
|
||
| * Intel\ |reg| Corporation Ethernet Server Adapter I350-T4 | ||
|
|
||
| * Firmware version: 1.63, 0x8000116b | ||
| * Device ID (PF/VF): 8086:1521 /8086:1520 | ||
| * Driver version: 6.14.0-35-generic (Ubuntu 24.04.3 LTS) (igb) | ||
|
|
||
| * Intel\ |reg| Infrastructure Processing Unit (Intel\ |reg| IPU) E2100 | ||
|
|
||
| * Firmware version: ci-ts.release.2.0.0.11126 | ||
| * Device ID (idpf/cpfl): 8086:1452/8086:1453 | ||
| * Driver version: 0.0.772 (idpf) | ||
|
|
||
| * Intel\ |reg| platforms with NVIDIA\ |reg| NICs combinations | ||
|
|
||
| * CPU: | ||
|
|
||
| * Intel\ |reg| Xeon\ |reg| Gold 6154 CPU @ 3.00GHz | ||
| * Intel\ |reg| Xeon\ |reg| CPU E5-2697A v4 @ 2.60GHz | ||
| * Intel\ |reg| Xeon\ |reg| CPU E5-2697 v3 @ 2.60GHz | ||
| * Intel\ |reg| Xeon\ |reg| CPU E5-2680 v2 @ 2.80GHz | ||
| * Intel\ |reg| Xeon\ |reg| CPU E5-2670 0 @ 2.60GHz | ||
| * Intel\ |reg| Xeon\ |reg| CPU E5-2650 v4 @ 2.20GHz | ||
| * Intel\ |reg| Xeon\ |reg| CPU E5-2650 v3 @ 2.30GHz | ||
| * Intel\ |reg| Xeon\ |reg| CPU E5-2640 @ 2.50GHz | ||
| * Intel\ |reg| Xeon\ |reg| CPU E5-2650 0 @ 2.00GHz | ||
| * Intel\ |reg| Xeon\ |reg| CPU E5-2620 v4 @ 2.10GHz | ||
|
|
||
| * OS: | ||
|
|
||
| * Red Hat Enterprise Linux release 9.2 (Plow) | ||
| * Red Hat Enterprise Linux release 9.1 (Plow) | ||
| * Red Hat Enterprise Linux release 8.6 (Ootpa) | ||
| * Ubuntu 24.04 | ||
| * Ubuntu 22.04 | ||
| * Ubuntu 20.04 | ||
| * SUSE Enterprise Linux 15 SP4 | ||
|
|
||
| * DOCA: | ||
|
|
||
| * DOCA 3.2.0-125000 and above. | ||
|
|
||
| * upstream kernel: | ||
|
|
||
| * Linux 6.17.0 and above | ||
|
|
||
| * rdma-core: | ||
|
|
||
| * rdma-core-58.0 and above | ||
|
|
||
| * NICs | ||
|
|
||
| * NVIDIA\ |reg| ConnectX\ |reg|-6 Dx EN 100G MCX623106AN-CDAT (2x100G) | ||
|
|
||
| * Host interface: PCI Express 4.0 x16 | ||
| * Device ID: 15b3:101d | ||
| * Firmware version: 22.47.1026 and above | ||
|
|
||
| * NVIDIA\ |reg| ConnectX\ |reg|-6 Lx EN 25G MCX631102AN-ADAT (2x25G) | ||
|
|
||
| * Host interface: PCI Express 4.0 x8 | ||
| * Device ID: 15b3:101f | ||
| * Firmware version: 26.47.1026 and above | ||
|
|
||
| * NVIDIA\ |reg| ConnectX\ |reg|-7 200G CX713106AE-HEA_QP1_Ax (2x200G) | ||
|
|
||
| * Host interface: PCI Express 5.0 x16 | ||
| * Device ID: 15b3:1021 | ||
| * Firmware version: 28.47.1026 and above | ||
|
|
||
| * NVIDIA\ |reg| ConnectX\ |reg|-8 SuperNIC 400G MT4131 - 900-9X81Q-00CN-STA (2x400G) | ||
|
|
||
| * Host interface: PCI Express 6.0 x16 | ||
| * Device ID: 15b3:1023 | ||
| * Firmware version: 40.47.1026 and above | ||
|
|
||
| * NVIDIA\ |reg| ConnectX\ |reg|-9 SuperNIC 800G MT4133 - 900-9X91E-00EB-STA_Ax (1x800G) | ||
|
|
||
| * Host interface: PCI Express 6.0 x16 | ||
| * Device ID: 15b3:1025 | ||
| * Firmware version: 82.47.0366 and above | ||
|
|
||
| * NVIDIA\ |reg| BlueField\ |reg| SmartNIC | ||
|
|
||
| * NVIDIA\ |reg| BlueField\ |reg|-2 SmartNIC MT41686 - MBF2H332A-AEEOT_A1 (2x25G) | ||
|
|
||
| * Host interface: PCI Express 3.0 x16 | ||
| * Device ID: 15b3:a2d6 | ||
| * Firmware version: 24.47.1026 and above | ||
|
|
||
| * NVIDIA\ |reg| BlueField\ |reg|-3 P-Series DPU MT41692 - 900-9D3B6-00CV-AAB (2x200G) | ||
|
|
||
| * Host interface: PCI Express 5.0 x16 | ||
| * Device ID: 15b3:a2dc | ||
| * Firmware version: 32.47.1026 and above | ||
|
|
||
| * Embedded software: | ||
|
|
||
| * Ubuntu 24.04 | ||
| * MLNX_OFED 25.10-1.2.8.0 | ||
| * bf-bundle-3.2.0-113_25.10_ubuntu-24.04 | ||
| * DPDK application running on ARM cores | ||
|
|
||
| * IBM Power 9 platforms with NVIDIA\ |reg| NICs combinations | ||
|
|
||
| * CPU: | ||
|
|
||
| * POWER9 2.2 (pvr 004e 1202) | ||
|
|
||
| * OS: | ||
|
|
||
| * Ubuntu 20.04 | ||
|
|
||
| * NICs: | ||
|
|
||
| * NVIDIA\ |reg| ConnectX\ |reg|-6 Dx 100G MCX623106AN-CDAT (2x100G) | ||
|
|
||
| * Host interface: PCI Express 4.0 x16 | ||
| * Device ID: 15b3:101d | ||
| * Firmware version: 22.47.1026 and above | ||
|
|
||
| * NVIDIA\ |reg| ConnectX\ |reg|-7 200G CX713106AE-HEA_QP1_Ax (2x200G) | ||
|
|
||
| * Host interface: PCI Express 5.0 x16 | ||
| * Device ID: 15b3:1021 | ||
| * Firmware version: 28.47.1026 and above | ||
|
|
||
| * DOCA: | ||
|
|
||
| * DOCA 3.2.0-125000 and above |
There was a problem hiding this comment.
Fix minor typo in Tested Platforms OS list.
Spelling of VMware is off in the OS list.
Suggested diff:
- * Vmware ESXi 8.0.3
+ * VMware ESXi 8.0.3📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| * Intel\ |reg| platforms with Intel\ |reg| NICs combinations | |
| * CPU | |
| * Intel\ |reg| Atom\ |trade| x7835RE | |
| * Intel\ |reg| Xeon\ |reg| 6553P-B CPU @ 2.6GHz | |
| * Intel\ |reg| Xeon\ |reg| 6767P CPU @ 2.4GHz | |
| * Intel\ |reg| Xeon\ |reg| CPU Max 9480 | |
| * Intel\ |reg| Xeon\ |reg| CPU Max 9480 CPU @ 1.9GHz | |
| * Intel\ |reg| Xeon\ |reg| Gold 6330 CPU @ 2.00GHz | |
| * Intel\ |reg| Xeon\ |reg| Gold 6348 CPU @ 2.60GHz | |
| * Intel\ |reg| Xeon\ |reg| Platinum 8280M CPU @ 2.70GHz | |
| * Intel\ |reg| Xeon\ |reg| Platinum 8380 CPU @ 2.30GHz | |
| * Intel\ |reg| Xeon\ |reg| Platinum 8468H CPU @ 2.1GHz | |
| * Intel\ |reg| Xeon\ |reg| Platinum 8490H CPU @ 1.9GHz | |
| * OS: | |
| * Fedora 42 | |
| * FreeBSD 14.3 | |
| * Microsoft Azure Linux 3.0 | |
| * OpenAnolis OS 8.10 | |
| * openEuler 24.03 (LTS-SP2) | |
| * Red Hat Enterprise Linux Server release 10 | |
| * Red Hat Enterprise Linux Server release 9.6 | |
| * Ubuntu 24.04 LTS | |
| * Ubuntu 24.04.3 LTS | |
| * Vmware ESXi 8.0.3 | |
| * NICs: | |
| * Intel\ |reg| Ethernet Controller E810-C for SFP (4x25G) | |
| * Firmware version: 4.90 0x80020eeb 1.3863.0 | |
| * Device ID (PF/VF): 8086:1593 / 8086:1889 | |
| * Driver version (out-of-tree): 2.3.14 (ice) | |
| * Driver version (in-tree): 6.8.0-86-generic (Ubuntu24.04 LTS) (ice) | |
| * OS Default DDP: 1.3.43.0 | |
| * COMMS DDP: 1.3.55.0 | |
| * Wireless Edge DDP: 1.3.25.0 | |
| * Intel\ |reg| Ethernet Controller E810-C for QSFP (2x100G) | |
| * Firmware version: 4.90 0x80020ef2 1.3863.0 | |
| * Device ID (PF/VF): 8086:1592 / 8086:1889 | |
| * Driver version (out-of-tree): 2.3.14 (ice) | |
| * Driver version (in-tree): 6.6.12.1-1.azl3+ice+ (Microsoft Azure Linux 3.0) / | |
| 6.12.0-55.9.1.el10_0.x86_64+rt (RHEL10) (ice) | |
| * OS Default DDP: 1.3.43.0 | |
| * COMMS DDP: 1.3.55.0 | |
| * Wireless Edge DDP: 1.3.25.0 | |
| * Intel\ |reg| Ethernet Controller E830-CC for SFP | |
| * Firmware version: 1.20 0x800179c0 1.3862.0 | |
| * Device ID (PF/VF): 8086:12d3 / 8086:1889 | |
| * Driver version: 2.3.14 (ice) | |
| * OS Default DDP: 1.3.43.0 | |
| * COMMS DDP: 1.3.55.0 | |
| * Wireless Edge DDP: 1.3.25.0 | |
| * Intel\ |reg| Ethernet Controller E830-CC for QSFP | |
| * Firmware version: 1.20 0x800179c1 1.3862.0 | |
| * Device ID (PF/VF): 8086:12d2 / 8086:1889 | |
| * Driver version: 2.3.14 (ice) | |
| * OS Default DDP: 1.3.43.0 | |
| * COMMS DDP: 1.3.55.0 | |
| * Wireless Edge DDP: 1.3.25.0 | |
| * Intel\ |reg| Ethernet Connection E825-C for QSFP | |
| * Firmware version: 4.04 0x80007e5c 1.3885.0 | |
| * Device ID (PF/VF): 8086:579d / 8086:1889 | |
| * Driver version: 2.3.14 (ice) | |
| * OS Default DDP: 1.3.43.0 | |
| * COMMS DDP: 1.3.55.0 | |
| * Wireless Edge DDP: 1.3.25.0 | |
| * Intel\ |reg| Ethernet Network Adapter E610-XT2 | |
| * Firmware version: 1.30 0x8000e8a2 1.3864.0 | |
| * Device ID (PF/VF): 8086:57b0 / 8086:57ad | |
| * Driver version (out-of-tree): 6.2.5 (ixgbe) | |
| * Intel\ |reg| Ethernet Network Adapter E610-XT4 | |
| * Firmware version: 1.30 0x8000e8a5 1.3864.0 | |
| * Device ID (PF/VF): 8086:57b0 / 8086:57ad | |
| * Driver version (out-of-tree): 6.2.5 (ixgbe) | |
| * Intel\ |reg| Ethernet Converged Network Adapter X710-DA4 (4x10G) | |
| * Firmware version: 9.55 0x8000fdf4 1.3862.0 | |
| * Device ID (PF/VF): 8086:1572 / 8086:154c | |
| * Driver version (in-tree): 6.8.0-88-generic (i40e) | |
| * Intel\ |reg| Corporation Ethernet Connection X722 for 10GbE SFP+ (2x10G) | |
| * Firmware version: 6.51 0x80004430 1.3862.0 | |
| * Device ID (PF/VF): 8086:37d0 / 8086:37cd | |
| * Driver version (out-of-tree): 2.28.13 (i40e) | |
| * Intel\ |reg| Ethernet Converged Network Adapter XXV710-DA2 (2x25G) | |
| * Firmware version: 9.55 0x8000fe4c 1.3862.0 | |
| * Device ID (PF/VF): 8086:158b / 8086:154c | |
| * Driver version (out-of-tree): 2.28.13 (i40e) | |
| * Driver version (in-tree): 6.8.0-88-generic (Ubuntu24.04.3 LTS) / | |
| 6.12.0-55.9.1.el10_0.x86_64 (RHEL10) (i40e) | |
| * Intel\ |reg| Ethernet Converged Network Adapter XL710-QDA2 (2X40G) | |
| * Firmware version(PF): 9.55 0x8000fe31 1.3862.0 | |
| * Device ID (PF/VF): 8086:1583 / 8086:154c | |
| * Driver version (out-of-tree): 2.28.13 (i40e) | |
| * Intel\ |reg| Ethernet Controller I226-LM | |
| * Firmware version: 2.14, 0x8000028c | |
| * Device ID (PF): 8086:125b | |
| * Driver version (in-tree): 6.8.0-87-generic (Ubuntu24.04.3 LTS) (igc) | |
| * Intel\ |reg| Corporation Ethernet Server Adapter I350-T4 | |
| * Firmware version: 1.63, 0x8000116b | |
| * Device ID (PF/VF): 8086:1521 /8086:1520 | |
| * Driver version: 6.14.0-35-generic (Ubuntu 24.04.3 LTS) (igb) | |
| * Intel\ |reg| Infrastructure Processing Unit (Intel\ |reg| IPU) E2100 | |
| * Firmware version: ci-ts.release.2.0.0.11126 | |
| * Device ID (idpf/cpfl): 8086:1452/8086:1453 | |
| * Driver version: 0.0.772 (idpf) | |
| * Intel\ |reg| platforms with NVIDIA\ |reg| NICs combinations | |
| * CPU: | |
| * Intel\ |reg| Xeon\ |reg| Gold 6154 CPU @ 3.00GHz | |
| * Intel\ |reg| Xeon\ |reg| CPU E5-2697A v4 @ 2.60GHz | |
| * Intel\ |reg| Xeon\ |reg| CPU E5-2697 v3 @ 2.60GHz | |
| * Intel\ |reg| Xeon\ |reg| CPU E5-2680 v2 @ 2.80GHz | |
| * Intel\ |reg| Xeon\ |reg| CPU E5-2670 0 @ 2.60GHz | |
| * Intel\ |reg| Xeon\ |reg| CPU E5-2650 v4 @ 2.20GHz | |
| * Intel\ |reg| Xeon\ |reg| CPU E5-2650 v3 @ 2.30GHz | |
| * Intel\ |reg| Xeon\ |reg| CPU E5-2640 @ 2.50GHz | |
| * Intel\ |reg| Xeon\ |reg| CPU E5-2650 0 @ 2.00GHz | |
| * Intel\ |reg| Xeon\ |reg| CPU E5-2620 v4 @ 2.10GHz | |
| * OS: | |
| * Red Hat Enterprise Linux release 9.2 (Plow) | |
| * Red Hat Enterprise Linux release 9.1 (Plow) | |
| * Red Hat Enterprise Linux release 8.6 (Ootpa) | |
| * Ubuntu 24.04 | |
| * Ubuntu 22.04 | |
| * Ubuntu 20.04 | |
| * SUSE Enterprise Linux 15 SP4 | |
| * DOCA: | |
| * DOCA 3.2.0-125000 and above. | |
| * upstream kernel: | |
| * Linux 6.17.0 and above | |
| * rdma-core: | |
| * rdma-core-58.0 and above | |
| * NICs | |
| * NVIDIA\ |reg| ConnectX\ |reg|-6 Dx EN 100G MCX623106AN-CDAT (2x100G) | |
| * Host interface: PCI Express 4.0 x16 | |
| * Device ID: 15b3:101d | |
| * Firmware version: 22.47.1026 and above | |
| * NVIDIA\ |reg| ConnectX\ |reg|-6 Lx EN 25G MCX631102AN-ADAT (2x25G) | |
| * Host interface: PCI Express 4.0 x8 | |
| * Device ID: 15b3:101f | |
| * Firmware version: 26.47.1026 and above | |
| * NVIDIA\ |reg| ConnectX\ |reg|-7 200G CX713106AE-HEA_QP1_Ax (2x200G) | |
| * Host interface: PCI Express 5.0 x16 | |
| * Device ID: 15b3:1021 | |
| * Firmware version: 28.47.1026 and above | |
| * NVIDIA\ |reg| ConnectX\ |reg|-8 SuperNIC 400G MT4131 - 900-9X81Q-00CN-STA (2x400G) | |
| * Host interface: PCI Express 6.0 x16 | |
| * Device ID: 15b3:1023 | |
| * Firmware version: 40.47.1026 and above | |
| * NVIDIA\ |reg| ConnectX\ |reg|-9 SuperNIC 800G MT4133 - 900-9X91E-00EB-STA_Ax (1x800G) | |
| * Host interface: PCI Express 6.0 x16 | |
| * Device ID: 15b3:1025 | |
| * Firmware version: 82.47.0366 and above | |
| * NVIDIA\ |reg| BlueField\ |reg| SmartNIC | |
| * NVIDIA\ |reg| BlueField\ |reg|-2 SmartNIC MT41686 - MBF2H332A-AEEOT_A1 (2x25G) | |
| * Host interface: PCI Express 3.0 x16 | |
| * Device ID: 15b3:a2d6 | |
| * Firmware version: 24.47.1026 and above | |
| * NVIDIA\ |reg| BlueField\ |reg|-3 P-Series DPU MT41692 - 900-9D3B6-00CV-AAB (2x200G) | |
| * Host interface: PCI Express 5.0 x16 | |
| * Device ID: 15b3:a2dc | |
| * Firmware version: 32.47.1026 and above | |
| * Embedded software: | |
| * Ubuntu 24.04 | |
| * MLNX_OFED 25.10-1.2.8.0 | |
| * bf-bundle-3.2.0-113_25.10_ubuntu-24.04 | |
| * DPDK application running on ARM cores | |
| * IBM Power 9 platforms with NVIDIA\ |reg| NICs combinations | |
| * CPU: | |
| * POWER9 2.2 (pvr 004e 1202) | |
| * OS: | |
| * Ubuntu 20.04 | |
| * NICs: | |
| * NVIDIA\ |reg| ConnectX\ |reg|-6 Dx 100G MCX623106AN-CDAT (2x100G) | |
| * Host interface: PCI Express 4.0 x16 | |
| * Device ID: 15b3:101d | |
| * Firmware version: 22.47.1026 and above | |
| * NVIDIA\ |reg| ConnectX\ |reg|-7 200G CX713106AE-HEA_QP1_Ax (2x200G) | |
| * Host interface: PCI Express 5.0 x16 | |
| * Device ID: 15b3:1021 | |
| * Firmware version: 28.47.1026 and above | |
| * DOCA: | |
| * DOCA 3.2.0-125000 and above | |
| * Intel\ |reg| platforms with Intel\ |reg| NICs combinations | |
| * CPU | |
| * Intel\ |reg| Atom\ |trade| x7835RE | |
| * Intel\ |reg| Xeon\ |reg| 6553P-B CPU @ 2.6GHz | |
| * Intel\ |reg| Xeon\ |reg| 6767P CPU @ 2.4GHz | |
| * Intel\ |reg| Xeon\ |reg| CPU Max 9480 | |
| * Intel\ |reg| Xeon\ |reg| CPU Max 9480 CPU @ 1.9GHz | |
| * Intel\ |reg| Xeon\ |reg| Gold 6330 CPU @ 2.00GHz | |
| * Intel\ |reg| Xeon\ |reg| Gold 6348 CPU @ 2.60GHz | |
| * Intel\ |reg| Xeon\ |reg| Platinum 8280M CPU @ 2.70GHz | |
| * Intel\ |reg| Xeon\ |reg| Platinum 8380 CPU @ 2.30GHz | |
| * Intel\ |reg| Xeon\ |reg| Platinum 8468H CPU @ 2.1GHz | |
| * Intel\ |reg| Xeon\ |reg| Platinum 8490H CPU @ 1.9GHz | |
| * OS: | |
| * Fedora 42 | |
| * FreeBSD 14.3 | |
| * Microsoft Azure Linux 3.0 | |
| * OpenAnolis OS 8.10 | |
| * openEuler 24.03 (LTS-SP2) | |
| * Red Hat Enterprise Linux Server release 10 | |
| * Red Hat Enterprise Linux Server release 9.6 | |
| * Ubuntu 24.04 LTS | |
| * Ubuntu 24.04.3 LTS | |
| * VMware ESXi 8.0.3 | |
| * NICs: | |
| * Intel\ |reg| Ethernet Controller E810-C for SFP (4x25G) | |
| * Firmware version: 4.90 0x80020eeb 1.3863.0 | |
| * Device ID (PF/VF): 8086:1593 / 8086:1889 | |
| * Driver version (out-of-tree): 2.3.14 (ice) | |
| * Driver version (in-tree): 6.8.0-86-generic (Ubuntu24.04 LTS) (ice) | |
| * OS Default DDP: 1.3.43.0 | |
| * COMMS DDP: 1.3.55.0 | |
| * Wireless Edge DDP: 1.3.25.0 | |
| * Intel\ |reg| Ethernet Controller E810-C for QSFP (2x100G) | |
| * Firmware version: 4.90 0x80020ef2 1.3863.0 | |
| * Device ID (PF/VF): 8086:1592 / 8086:1889 | |
| * Driver version (out-of-tree): 2.3.14 (ice) | |
| * Driver version (in-tree): 6.6.12.1-1.azl3+ice+ (Microsoft Azure Linux 3.0) / | |
| 6.12.0-55.9.1.el10_0.x86_64+rt (RHEL10) (ice) | |
| * OS Default DDP: 1.3.43.0 | |
| * COMMS DDP: 1.3.55.0 | |
| * Wireless Edge DDP: 1.3.25.0 | |
| * Intel\ |reg| Ethernet Controller E830-CC for SFP | |
| * Firmware version: 1.20 0x800179c0 1.3862.0 | |
| * Device ID (PF/VF): 8086:12d3 / 8086:1889 | |
| * Driver version: 2.3.14 (ice) | |
| * OS Default DDP: 1.3.43.0 | |
| * COMMS DDP: 1.3.55.0 | |
| * Wireless Edge DDP: 1.3.25.0 | |
| * Intel\ |reg| Ethernet Controller E830-CC for QSFP | |
| * Firmware version: 1.20 0x800179c1 1.3862.0 | |
| * Device ID (PF/VF): 8086:12d2 / 8086:1889 | |
| * Driver version: 2.3.14 (ice) | |
| * OS Default DDP: 1.3.43.0 | |
| * COMMS DDP: 1.3.55.0 | |
| * Wireless Edge DDP: 1.3.25.0 | |
| * Intel\ |reg| Ethernet Connection E825-C for QSFP | |
| * Firmware version: 4.04 0x80007e5c 1.3885.0 | |
| * Device ID (PF/VF): 8086:579d / 8086:1889 | |
| * Driver version: 2.3.14 (ice) | |
| * OS Default DDP: 1.3.43.0 | |
| * COMMS DDP: 1.3.55.0 | |
| * Wireless Edge DDP: 1.3.25.0 | |
| * Intel\ |reg| Ethernet Network Adapter E610-XT2 | |
| * Firmware version: 1.30 0x8000e8a2 1.3864.0 | |
| * Device ID (PF/VF): 8086:57b0 / 8086:57ad | |
| * Driver version (out-of-tree): 6.2.5 (ixgbe) | |
| * Intel\ |reg| Ethernet Network Adapter E610-XT4 | |
| * Firmware version: 1.30 0x8000e8a5 1.3864.0 | |
| * Device ID (PF/VF): 8086:57b0 / 8086:57ad | |
| * Driver version (out-of-tree): 6.2.5 (ixgbe) | |
| * Intel\ |reg| Ethernet Converged Network Adapter X710-DA4 (4x10G) | |
| * Firmware version: 9.55 0x8000fdf4 1.3862.0 | |
| * Device ID (PF/VF): 8086:1572 / 8086:154c | |
| * Driver version (in-tree): 6.8.0-88-generic (i40e) | |
| * Intel\ |reg| Corporation Ethernet Connection X722 for 10GbE SFP+ (2x10G) | |
| * Firmware version: 6.51 0x80004430 1.3862.0 | |
| * Device ID (PF/VF): 8086:37d0 / 8086:37cd | |
| * Driver version (out-of-tree): 2.28.13 (i40e) | |
| * Intel\ |reg| Ethernet Converged Network Adapter XXV710-DA2 (2x25G) | |
| * Firmware version: 9.55 0x8000fe4c 1.3862.0 | |
| * Device ID (PF/VF): 8086:158b / 8086:154c | |
| * Driver version (out-of-tree): 2.28.13 (i40e) | |
| * Driver version (in-tree): 6.8.0-88-generic (Ubuntu24.04.3 LTS) / | |
| 6.12.0-55.9.1.el10_0.x86_64 (RHEL10) (i40e) | |
| * Intel\ |reg| Ethernet Converged Network Adapter XL710-QDA2 (2X40G) | |
| * Firmware version(PF): 9.55 0x8000fe31 1.3862.0 | |
| * Device ID (PF/VF): 8086:1583 / 8086:154c | |
| * Driver version (out-of-tree): 2.28.13 (i40e) | |
| * Intel\ |reg| Ethernet Controller I226-LM | |
| * Firmware version: 2.14, 0x8000028c | |
| * Device ID (PF): 8086:125b | |
| * Driver version (in-tree): 6.8.0-87-generic (Ubuntu24.04.3 LTS) (igc) | |
| * Intel\ |reg| Corporation Ethernet Server Adapter I350-T4 | |
| * Firmware version: 1.63, 0x8000116b | |
| * Device ID (PF/VF): 8086:1521 /8086:1520 | |
| * Driver version: 6.14.0-35-generic (Ubuntu 24.04.3 LTS) (igb) | |
| * Intel\ |reg| Infrastructure Processing Unit (Intel\ |reg| IPU) E2100 | |
| * Firmware version: ci-ts.release.2.0.0.11126 | |
| * Device ID (idpf/cpfl): 8086:1452/8086:1453 | |
| * Driver version: 0.0.772 (idpf) | |
| * Intel\ |reg| platforms with NVIDIA\ |reg| NICs combinations | |
| * CPU: | |
| * Intel\ |reg| Xeon\ |reg| Gold 6154 CPU @ 3.00GHz | |
| * Intel\ |reg| Xeon\ |reg| CPU E5-2697A v4 @ 2.60GHz | |
| * Intel\ |reg| Xeon\ |reg| CPU E5-2697 v3 @ 2.60GHz | |
| * Intel\ |reg| Xeon\ |reg| CPU E5-2680 v2 @ 2.80GHz | |
| * Intel\ |reg| Xeon\ |reg| CPU E5-2670 0 @ 2.60GHz | |
| * Intel\ |reg| Xeon\ |reg| CPU E5-2650 v4 @ 2.20GHz | |
| * Intel\ |reg| Xeon\ |reg| CPU E5-2650 v3 @ 2.30GHz | |
| * Intel\ |reg| Xeon\ |reg| CPU E5-2640 @ 2.50GHz | |
| * Intel\ |reg| Xeon\ |reg| CPU E5-2650 0 @ 2.00GHz | |
| * Intel\ |reg| Xeon\ |reg| CPU E5-2620 v4 @ 2.10GHz | |
| * OS: | |
| * Red Hat Enterprise Linux release 9.2 (Plow) | |
| * Red Hat Enterprise Linux release 9.1 (Plow) | |
| * Red Hat Enterprise Linux release 8.6 (Ootpa) | |
| * Ubuntu 24.04 | |
| * Ubuntu 22.04 | |
| * Ubuntu 20.04 | |
| * SUSE Enterprise Linux 15 SP4 | |
| * DOCA: | |
| * DOCA 3.2.0-125000 and above. | |
| * upstream kernel: | |
| * Linux 6.17.0 and above | |
| * rdma-core: | |
| * rdma-core-58.0 and above | |
| * NICs | |
| * NVIDIA\ |reg| ConnectX\ |reg|-6 Dx EN 100G MCX623106AN-CDAT (2x100G) | |
| * Host interface: PCI Express 4.0 x16 | |
| * Device ID: 15b3:101d | |
| * Firmware version: 22.47.1026 and above | |
| * NVIDIA\ |reg| ConnectX\ |reg|-6 Lx EN 25G MCX631102AN-ADAT (2x25G) | |
| * Host interface: PCI Express 4.0 x8 | |
| * Device ID: 15b3:101f | |
| * Firmware version: 26.47.1026 and above | |
| * NVIDIA\ |reg| ConnectX\ |reg|-7 200G CX713106AE-HEA_QP1_Ax (2x200G) | |
| * Host interface: PCI Express 5.0 x16 | |
| * Device ID: 15b3:1021 | |
| * Firmware version: 28.47.1026 and above | |
| * NVIDIA\ |reg| ConnectX\ |reg|-8 SuperNIC 400G MT4131 - 900-9X81Q-00CN-STA (2x400G) | |
| * Host interface: PCI Express 6.0 x16 | |
| * Device ID: 15b3:1023 | |
| * Firmware version: 40.47.1026 and above | |
| * NVIDIA\ |reg| ConnectX\ |reg|-9 SuperNIC 800G MT4133 - 900-9X91E-00EB-STA_Ax (1x800G) | |
| * Host interface: PCI Express 6.0 x16 | |
| * Device ID: 15b3:1025 | |
| * Firmware version: 82.47.0366 and above | |
| * NVIDIA\ |reg| BlueField\ |reg| SmartNIC | |
| * NVIDIA\ |reg| BlueField\ |reg|-2 SmartNIC MT41686 - MBF2H332A-AEEOT_A1 (2x25G) | |
| * Host interface: PCI Express 3.0 x16 | |
| * Device ID: 15b3:a2d6 | |
| * Firmware version: 24.47.1026 and above | |
| * NVIDIA\ |reg| BlueField\ |reg|-3 P-Series DPU MT41692 - 900-9D3B6-00CV-AAB (2x200G) | |
| * Host interface: PCI Express 5.0 x16 | |
| * Device ID: 15b3:a2dc | |
| * Firmware version: 32.47.1026 and above | |
| * Embedded software: | |
| * Ubuntu 24.04 | |
| * MLNX_OFED 25.10-1.2.8.0 | |
| * bf-bundle-3.2.0-113_25.10_ubuntu-24.04 | |
| * DPDK application running on ARM cores | |
| * IBM Power 9 platforms with NVIDIA\ |reg| NICs combinations | |
| * CPU: | |
| * POWER9 2.2 (pvr 004e 1202) | |
| * OS: | |
| * Ubuntu 20.04 | |
| * NICs: | |
| * NVIDIA\ |reg| ConnectX\ |reg|-6 Dx 100G MCX623106AN-CDAT (2x100G) | |
| * Host interface: PCI Express 4.0 x16 | |
| * Device ID: 15b3:101d | |
| * Firmware version: 22.47.1026 and above | |
| * NVIDIA\ |reg| ConnectX\ |reg|-7 200G CX713106AE-HEA_QP1_Ax (2x200G) | |
| * Host interface: PCI Express 5.0 x16 | |
| * Device ID: 15b3:1021 | |
| * Firmware version: 28.47.1026 and above | |
| * DOCA: | |
| * DOCA 3.2.0-125000 and above |
🤖 Prompt for AI Agents
In doc/guides/rel_notes/release_25_11.rst around lines 349 to 600, there's a
typo in the OS list where "Vmware ESXi 8.0.3" should be corrected to "VMware
ESXi 8.0.3"; update the spelling/capitalization to "VMware" to match the proper
product name and ensure consistency with other entries.
| extern uint32_t rx_burst_size; | ||
| extern uint32_t mb_mempool_cache_size; | ||
|
|
There was a problem hiding this comment.
TX burst threshold in send_single_packet is wired to RX size, not TX size
send_single_packet() now flushes the TX buffer when:
len = qconf->tx_mbufs[port].len;
...
if (unlikely(len == rx_burst_size)) {
send_burst(qconf, rx_burst_size, port);
len = 0;
}while l3fwd_common.h introduces a separate tx_burst_size and uses it in send_packetsx4() as the TX threshold.
This creates two problems:
--tx-burstis not honored in this path – TX flush behavior fromsend_single_packet()still depends onrx_burst_size, so tuning--tx-burstwill not affect this common code path.- RX/TX coupling – RX and TX thresholds are unintentionally tied together here, defeating the purpose of per-direction burst sizing.
Unless there is a deliberate reason to share the RX threshold for this particular path, it looks like this should use tx_burst_size instead of rx_burst_size both for the comparison and for the send_burst() count.
Suggested fix:
-extern uint32_t rx_burst_size;
+extern uint32_t rx_burst_size;
+extern uint32_t tx_burst_size; /* if not already visible here */
...
- /* 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;
}This would make both TX paths (send_single_packet and send_packetsx4) consistently controlled by tx_burst_size and keep RX and TX burst tuning independent, as the new CLI options imply.
Also applies to: 141-153
🤖 Prompt for AI Agents
In examples/l3fwd/l3fwd.h around lines 115-117 (and also apply the same change
at lines 141-153), the TX flush in send_single_packet is incorrectly using
rx_burst_size; change the comparison and the send_burst call to use
tx_burst_size instead so that send_single_packet flushes based on the transmit
burst threshold; update both occurrences to call send_burst(qconf,
tx_burst_size, port) and compare len against tx_burst_size to keep RX and TX
burst sizing independent.
NOTE: This is an auto submission for "[v4] event/cnxk: fix offload flags".
See "http://patchwork.dpdk.org/project/dpdk/list/?series=36802" for details.
Summary by Sourcery
Refine burst size handling, link speed configuration, and buffer sizing across examples while aligning cnxk eventdev offload flags and mlx5 flex parser behavior with updated hardware capabilities and removing unused steering modes.
New Features:
Bug Fixes:
Enhancements:
Build:
Documentation:
Summary by CodeRabbit
New Features
Documentation
Chores
✏️ Tip: You can customize this high-level summary in your review settings.