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

[dpdklab at iol.unh.edu]

Test-Label: ai-code-review
Test-Status: WARNING
https://dpdk.org/patch/172151

_AI Code Review_

=== Patch Review: series.patch (via Claude) ===
Review date: 2026-10-27

# DPDK Patch Review

## ERRORS

### Error: Stale MTU-Related Field Access

**Line 4504:**
```c
if ((dev->data->dev_conf.rxmode.mq_mode & RTE_ETH_MQ_RX_VMDQ_FLAG) == 0) {
```

This accesses `dev->data->dev_conf.rxmode.mq_mode` after device configuration.
The `dev_conf` structure contains the user's *request* passed to `rte_eth_dev_configure()`
and becomes stale if configuration is changed later.

While `rxmode.mq_mode` (unlike `rxmode.mtu`) is not currently known to be modified after configure,
the pattern violates the canonical rule: after `rte_eth_dev_configure()` completes,
PMDs should read device state from `dev->data->*` fields, not from `dev_conf`.

For multi-queue mode specifically, there is no canonical `dev->data` field that tracks
the current Rx multi-queue mode. However, this function is removing a MAC address,
which requires knowing whether VMDq pool assignment is active.

**Why it matters:**
The code reads configuration state that may not reflect the current device state.
If the ethdev API later allows runtime reconfiguration of multi-queue mode,
this will break.

**Suggested fix:**
The correct check is whether VMDq pools are actually being used, which means checking
if `mac_pool_sel[]` is populated. Since ethdev only sets `mac_pool_sel[index]`
when VMDq mode is configured, checking if it's non-zero tells you if pool-based
removal is needed:

```c
/* VMDq is active if ethdev populated the pool selector for this address */
if (data->mac_pool_sel[index] == 0) {
	if (i40e_vsi_delete_mac(pf->main_vsi, macaddr) != 0)
		PMD_DRV_LOG(ERR, "Failed to remove MACVLAN filter");
	return;
}
```

This matches what ethdev does: it sets `mac_pool_sel[index]` to a non-zero value
only when VMDq is configured, so a zero value means "not in a VMDq pool,
remove from main VSI".

---

## FINAL CHECK

Pass 1 (correctness bugs): Covered stale config field access.

Pass 2 (false positives): No style/process items flagged as correct then contradicted.

Pass 3 (evidence):
- Finding references line 4504, which is the changed line (added `+` in diff).
- Quote is verbatim from the patch.
- The quoted line shows the defect claimed (reading `dev_conf` after configure).
- No hedging about code content.
- Suggested fix uses current API (`dev->data` fields).

Review-Result: ERROR