|SUCCESS| [v2] net/ice: fix max number of descriptors for E830

[dpdklab at iol.unh.edu]

Test-Label: ai-code-review
Test-Status: SUCCESS
https://dpdk.org/patch/171072

_AI Code Review_

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

# DPDK Patch Review

## Severity: CLEAN

### Analysis

This patch fixes an issue where E830 hardware was advertising descriptor limits higher than what the hardware actually supports, which could lead to Malicious Driver Detection events when Tx packet pacing is enabled.

**Correctness verification:**

1. **No resource leaks:** The patch only modifies constant values used in validation and info structures. No resource allocation or cleanup paths are affected.

2. **No use-after-free:** No memory management changes.

3. **No race conditions:** Changes are to read-only configuration values returned by `ice_dev_info_get()` and validation checks in queue setup functions.

4. **Boundary checking:** The patch correctly tightens bounds checking by using `ICE_MAX_NUM_DESC_BY_MAC(hw)` which returns the appropriate limit based on hardware type (8096 for E830, 8160 for others).

5. **Logic correctness:** The fix ensures consistency across three locations:
   - `dev_info->rx_desc_lim.nb_max` (advertised Rx limit)
   - `dev_info->tx_desc_lim.nb_max` and `nb_seg_max` (advertised Tx limits)
   - Validation in `ice_rx_queue_setup()` and `ice_tx_queue_setup()`
   
   All now use the same macro that was already being used for actual ring allocation, eliminating the discrepancy.

**Code style verification:**

1. **Indentation and formatting:** Consistent with surrounding code.

2. **Comments:** The added comment appropriately explains why `ICE_MAX_NUM_DESC_BY_MAC()` should be used instead of the raw `ICE_MAX_RING_DESC` constant.

3. **Naming conventions:** Uses existing DPDK/driver conventions.

4. **No forbidden tokens:** No use of deprecated APIs, incorrect atomics, or other forbidden patterns.

**Process compliance:**

1. **Fixes tag present:** Correctly references the commit that introduced the issue.

2. **Cc: stable present:** Appropriate for a bug fix.

3. **Atomicity:** Code and comment added together in the same patch.

4. **Documentation:** While release notes are not included in this patch file, this type of bug fix (correcting advertised limits to match hardware capabilities) would typically warrant a mention in the fixes section of release notes. However, per the guidelines, test-only changes and internal implementation fixes may not require release notes. This is a borderline case - it fixes a functional bug but doesn't change the public API surface. The absence of release note updates is acceptable.

**No findings to report.**

Review-Result: CLEAN