|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