|SUCCESS| net/i40e: fix MAC address removal without VMDq
dpdklab at iol.unh.edu
dpdklab at iol.unh.edu
Tue Oct 27 12:06:30 CET 2026
Test-Label: ai-code-review
Test-Status: SUCCESS
https://dpdk.org/patch/172151
_AI Code Review_
=== Patch Review: series.patch (via Claude) ===
Review date: 2026-10-27
# DPDK Patch Review
## Errors
None.
## Warnings
**MTU handling - reading dev_conf.rxmode field**
**Line:** `if ((dev->data->dev_conf.rxmode.mq_mode & RTE_ETH_MQ_RX_VMDQ_FLAG) == 0) {`
The patch reads `dev->data->dev_conf.rxmode.mq_mode` to determine if VMDq is configured. This is acceptable for the multi-queue mode field, which unlike `dev_conf.rxmode.mtu`, does not have a separate canonical location and is not stale after configure.
However, the pattern warrants review: ethdev itself manages `mac_pool_sel[]` based on `rxmode.mq_mode & RTE_ETH_MQ_RX_VMDQ_FLAG` (see `lib/ethdev/rte_ethdev.c`). The PMD is correctly matching that condition.
No issue here - this is the correct check for VMDq configuration state.
Actually, upon final review: this is correct usage. The `mq_mode` field does not have the same staleness issue as `mtu` because there is no separate runtime storage for it. Withdraw this item.
## Info
None.
---
**FINAL ASSESSMENT**
The patch correctly addresses a logic error where the driver checked hardware capability (`I40E_FLAG_VMDQ`) instead of runtime configuration state (`rxmode.mq_mode & RTE_ETH_MQ_RX_VMDQ_FLAG`). The new condition matches the one ethdev uses to populate `mac_pool_sel[]`, ensuring consistency.
The fix is appropriate and follows the established pattern in the ethdev layer.
Review-Result: CLEAN
More information about the test-report
mailing list