|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

# Review of DPDK Patch: net/sxe2 Build Fix

## Summary
This patch fixes a build failure in the sxe2 driver when optional libraries are disabled. The change replaces hand-rolled meson static library creation with standard DPDK patterns using `sources_avx2` and `sources_avx512`.

## Errors

None found.

## Warnings

**Missing release notes update** (Warning):
This patch fixes a build failure that would occur when building DPDK with minimal library configuration. Such fixes should be documented in the current release notes under a "Fixed Issues" or "Build" section.

Add an entry to `doc/guides/rel_notes/release_26_03.rst` (or the appropriate current release) documenting this build fix, for example:
```rst
* **Fixed sxe2 driver build with minimal library configuration.**

  Fixed build failure in sxe2 driver when security library is disabled
  by replacing hand-rolled meson static library pattern with standard
  DPDK AVX2/AVX512 source handling.
```

## Info

**Pattern improvement** (Info):
The new approach using `sources_avx2` and `sources_avx512` is correct and follows DPDK standard patterns. This is preferable to the hand-rolled static library approach for several reasons:

1. Automatically handles CPU capability detection
2. Avoids hardcoded dependency lists that can break when libraries are disabled
3. Integrates with DPDK's existing ISA-specific build infrastructure
4. More maintainable as it follows established conventions in other DPDK drivers

The removed code had several issues that the new approach fixes:
- Hardcoded dependency on `static_rte_security` and `static_rte_cryptodev` which may not exist
- Manual CPU feature detection that duplicates DPDK infrastructure
- Custom compiler flag management instead of using DPDK's centralized handling

This is a good cleanup that aligns the driver with DPDK best practices.

---

**Overall Assessment**: The code change is correct and follows DPDK standards. Only missing documentation in release notes.