|SUCCESS| net/i40e: fix MAC address removal without VMDq

[dpdklab at iol.unh.edu]

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

**Error 1: Reading stale MTU value from dev_conf**

The patch reads `dev->data->dev_conf.rxmode.mq_mode` directly.
While this is not the MTU field specifically covered in the guidelines,
the same principle applies to configuration fields read after `rte_eth_dev_configure()`:
the canonical state for runtime decisions should come from `dev->data`, not from `dev_conf`.

However, in this specific case, `mq_mode` appears to be read-only after configure
and is not modified by runtime operations like `rte_eth_dev_set_mtu()` would change MTU.
Upon closer inspection, ethdev does not provide a separate canonical copy of `mq_mode`
outside of `dev_conf.rxmode.mq_mode`, so this access pattern may be the only option available.

**Correction: This is not a stale-read issue.**
The `mq_mode` field is set once at configure time and is not modified afterward by ethdev or PMDs.
Reading it from `dev_conf` is the intended pattern for this field.
No error here.

## WARNINGS

None.

## INFO

**Info 1: Logic inversion may benefit from a comment**

The original code checked `if (!(pf->flags & I40E_FLAG_VMDQ))` (hardware supports VMDq)
and the fix changes this to `if ((dev->data->dev_conf.rxmode.mq_mode & RTE_ETH_MQ_RX_VMDQ_FLAG) == 0)` (VMDq mode not configured).

These are semantically different conditions:
- Old: "hardware does NOT support VMDq"
- New: "VMDq mode is NOT configured"

The commit message explains this is intentional (the bug was conflating hardware capability with configuration state),
but a brief inline comment would help future readers understand why we check configuration rather than capability:

```c
/* Use non-pool removal when VMDq is not configured.
 * ethdev only populates mac_pool_sel[] when VMDq mode is active.
 */
if ((dev->data->dev_conf.rxmode.mq_mode & RTE_ETH_MQ_RX_VMDQ_FLAG) == 0) {
```

This is a clarity suggestion, not a requirement.

---

**FINAL CHECK:**

Pass 1 (correctness bugs): Verified error path cleanup (none in this patch), checked for use-after-free (none), error propagation (function returns void, no propagation needed).

Pass 2 (style false positives): The initial MTU concern was disproven by checking that `mq_mode` has no separate canonical copy and is read-only after configure. No remaining style items claim "actually fine/correct" - all were deleted during analysis.

Pass 3 (evidence): The Info item references line 4504 in the patch (the changed condition), which is an added line, and the claim (logic difference) is supported by that line. Evidence is present.

The patch correctly fixes a logic bug where hardware capability was checked instead of actual configuration state, matching the condition ethdev uses to populate `mac_pool_sel[]`.

Review-Result: CLEAN