|WARNING| net/sxe2: fix build when optional libraries are disabled

[dpdklab at iol.unh.edu]

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

_AI Code Review_

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

# DPDK Patch Review

## Summary
This patch fixes a build failure in the sxe2 driver when optional libraries (specifically security library) are disabled. The fix replaces hand-rolled meson static library builds with the standard DPDK `sources_avx2` and `sources_avx512` variables.

## Findings

### Errors

None found. The patch correctly addresses the build failure.

### Warnings

**1. Missing release notes update**

This patch fixes bugs (build failures) in existing code but does not update the release notes. While the change is in a driver (not public API), significant bug fixes affecting build configurations should typically be mentioned in the release notes.

Suggested action: Add an entry to `doc/guides/rel_notes/release_26_11.rst` (or current release) under a "Fixed Issues" or "Drivers" section:

```rst
* **net/sxe2: Fixed build with minimal library configuration.**

  Fixed build failure when building with subset of DPDK libraries enabled.
  The driver now uses standard meson source variables instead of manual
  static library construction.
```

**2. Lost CPU feature detection logic**

The original code included runtime CPU feature detection:
```c
sxe2_avx512_cpu_support =(
    cc.get_define('__AVX512F__', args: machine_args) != '' and
    cc.get_define('__AVX512BW__', args: machine_args) != '')
```

This logic conditionally defined `CC_AVX512_SUPPORT` which may be used in the driver code to select AVX512 code paths. The new implementation unconditionally adds the AVX512 source file to `sources_avx512`, which may change runtime behavior.

Suggested action: Verify that the driver code in `sxe2_txrx_vec_avx512.c` is protected by appropriate runtime CPU feature checks, or that the DPDK build system's handling of `sources_avx512` provides equivalent functionality. If the `CC_AVX512_SUPPORT` macro was actually used in source code, its removal could break the driver.

**3. Removed AVX2 compilation**

The original code always compiled AVX2 sources (`sxe2_avx2_lib`), but the new code adds it to `sources_avx2` which may not be compiled on all platforms or configurations.

Suggested action: Verify that `sources_avx2` is handled correctly by the DPDK build system for this driver and that AVX2 support is still built when needed.

### Info

**1. Standard pattern adoption**

The patch correctly adopts the standard DPDK pattern for architecture-specific sources. The `sources_avx2` and `sources_avx512` variables are the preferred mechanism in DPDK for handling vectorized code compilation, and the build system handles the CPU feature detection and compiler flag selection automatically.

**2. Dependency cleanup**

The original code had explicit dependencies on `static_rte_security` and `static_rte_cryptodev` which were the root cause of the build failure. The new approach lets the build system handle dependencies automatically, which is more maintainable.

## Correctness Check

- No use-after-free issues
- No resource leaks
- No race conditions
- No forbidden tokens introduced
- No C coding style violations
- Meson syntax appears correct
- No ABI/API changes

## Conclusion

The patch correctly fixes the immediate build failure. However, the removal of explicit CPU feature detection logic and the change in how AVX2/AVX512 sources are compiled should be verified to ensure no runtime behavior regression. The impact depends on how the build system handles `sources_avx2` and `sources_avx512`, and whether the driver code relied on the `CC_AVX512_SUPPORT` macro.