|WARNING| net/iavf: fix QinQ handling when only inner VLAN capability is supported

[dpdklab at iol.unh.edu]

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

_AI Code Review_

=== Patch Review: series.patch (via Claude) ===
Review date: 2026-07-02

# DPDK Patch Review

## Patch Summary
This patch fixes QinQ (VLAN stacking) handling in the iavf driver when hardware reports Single VLAN capability through inner VLAN capabilities instead of outer VLAN capabilities.

---

## Review Findings

### **Errors**

None identified.

### **Warnings**

None identified.

### **Info**

**Logic simplification opportunity:**

The patch modifies two conditional blocks that share the same pattern. After the change, both functions have:

```c
else if ((stripping_caps->inner & VIRTCHNL_VLAN_ETHERTYPE_8100) &&
         (stripping_caps->inner & VIRTCHNL_VLAN_TOGGLE))
```

This condition no longer depends on the `qinq` variable. The logic could be simplified:

**In `iavf_config_vlan_strip_v2()`:**
```c
if (!qinq && (stripping_caps->outer & VIRTCHNL_VLAN_ETHERTYPE_8100) &&
    (stripping_caps->outer & VIRTCHNL_VLAN_TOGGLE))
    ethertype = &vlan_strip.outer_ethertype_setting;
else if ((stripping_caps->inner & VIRTCHNL_VLAN_ETHERTYPE_8100) &&
         (stripping_caps->inner & VIRTCHNL_VLAN_TOGGLE))
    ethertype = &vlan_strip.inner_ethertype_setting;
else
    return -ENOTSUP;
```

This means:
- If not in QinQ mode AND outer caps support 8100 with toggle - use outer
- Otherwise, if inner caps support 8100 with toggle - use inner
- Otherwise - not supported

The logic now handles three cases:
1. Single VLAN via outer caps (`!qinq` path)
2. Single VLAN via inner caps OR QinQ via inner caps (merged `else if`)
3. Neither supported

**Suggest verifying:** Does the hardware ever report both inner and outer capabilities simultaneously? If so, does this new precedence (outer first, then inner) correctly handle all hardware configurations?

The same pattern and consideration applies to `iavf_config_vlan_insert_v2()`.

---

## Summary

The patch is **correct** from a coding standards and safety perspective. The logic change appears to address the issue described (supporting hardware that reports Single VLAN ops via inner caps), but the reviewers should verify the precedence order matches hardware behavior when both inner and outer capabilities are present.

**Recommendation:** Accept with consideration of the Info note above for testing coverage.