|WARNING| net/crc: add 4x folding loop for aarch64 NEON implementation

[dpdklab at iol.unh.edu]

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

_AI Code Review_

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

# DPDK Patch Review

## Summary
This patch adds a 4x folding loop optimization to the aarch64 NEON CRC implementation. The code is well-structured and follows the Intel PCLMULQDQ paper's approach. I found no correctness bugs or memory safety issues.

## Findings

### Errors
None.

### Warnings

**1. Missing release notes update**
The patch adds a significant performance optimization (roughly 2x improvement for large inputs) but does not update the release notes.

Add an entry to `doc/guides/rel_notes/release_XX_YY.rst` documenting this performance improvement:
```rst
* **Improved CRC performance on aarch64.**

  Implemented 4x parallel folding in the NEON CRC computation, resulting in
  approximately 2x performance improvement for large input sizes (1024+ bytes)
  on Cortex-X925 and similar cores.
```

**2. Magic constant `64` appears multiple times without a define**
The new loop processes 64 bytes at a time. This value appears in multiple places (loop condition, offset calculations) without a symbolic constant.

Consider adding at the top of the function:
```c
#define CRC_PARALLEL_FOLD_SIZE 64
```
Then use it consistently:
```c
if (likely(data_len >= CRC_PARALLEL_FOLD_SIZE)) {
    ...
    for (n = CRC_PARALLEL_FOLD_SIZE; 
         (n + CRC_PARALLEL_FOLD_SIZE) <= data_len; 
         n += CRC_PARALLEL_FOLD_SIZE) {
```

**3. Label name `single_fold_loop` could be more descriptive**
The goto target name doesn't clearly indicate it's the fallback/remainder processing path.

Consider renaming to `fold_remaining` or `remainder_fold_loop` for clarity.

### Info

**1. Comment consistency**
The multi-line comment style mixes `/**` (Doxygen-style) with algorithm explanation comments. While not incorrect, algorithm comments could use the simpler `/*` style for consistency with the rest of the file.

**2. Variable naming**
The variables `temp1`, `temp2`, `temp3`, `temp4` and `fold1`, `fold2`, `fold3`, `fold4` are clear in context but could be slightly more descriptive (e.g., `fold_acc0` through `fold_acc3`). This is a minor style preference.

**3. Alignment of fold register declarations**
The four fold register declarations could be aligned vertically for readability:
```c
uint64x2_t fold1, fold2, fold3, fold4;
uint64x2_t temp1, temp2, temp3, temp4;
```
is fine, but some codebases prefer one declaration per line in such performance-critical sections to make the register usage more explicit.

## Positive Observations

1. **Correct algorithm**: The 4x parallel folding with reduction to single fold matches the Intel paper's approach
2. **No resource leaks**: All paths properly handle memory
3. **Good use of `likely()`/`unlikely()`**: Branch hints are appropriate for the common case (large buffers)
4. **Proper constants**: The new k1_k2 and k3_k4 constants are correctly computed for the parallel folding reduction
5. **Preserved edge cases**: Handling of small buffers (< 4 bytes, < 16 bytes) is unchanged and correct

## Recommendation

The patch is **acceptable for merge** after addressing the missing release notes (Warning #1). The magic constant define (Warning #2) and label naming (Warning #3) are optional improvements.