|SUCCESS| [v8] pcapng: add user-supplied timestamp support

[dpdklab at iol.unh.edu]

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

_AI Code Review_

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

# DPDK Patch Review

## Patch Summary
This patch adds user-supplied timestamp support to the pcapng library, allowing applications to provide hardware timestamps or other time sources instead of always using the TSC at copy time.

## ERRORS

None found.

## WARNINGS

None found.

## INFO

### Pre-existing code observation
In `lib/pcapng/rte_pcapng.c` line 575, the existing code has:
```c
pkt_len = rte_pktmbuf_data_len(mc);
```
This line appears in context but is not modified by the patch. The variable `pkt_len` is later overwritten at line 586 without the initial value being read:
```c
pkt_len = RTE_ALIGN(orig_len, sizeof(uint32_t));
```
This is a dead store - the first assignment can be removed. However, this is pre-existing code that the patch does not touch.

### Documentation clarity
The release notes clearly document the API change and the bit 63 constraint. The programmer's guide update appropriately explains the timestamp behavior. The documentation matches the implementation.

### Test coverage
The new `test_pcapng_timestamp()` function provides good coverage:
- Tests rejection of timestamp with bit 63 set
- Tests custom timestamp storage and retrieval
- Verifies the timestamp appears correctly in the pcapng file

The test correctly uses `mkstemps()` for temporary file creation and cleans up with `remove()` on all paths.

### Implementation correctness
The timestamp flag mechanism is sound:
- Bit 63 is used to distinguish TSC values from epoch nanoseconds
- The constraint that bit 63 cannot be set in caller timestamps is enforced
- Epoch nanoseconds won't naturally set bit 63 until year 2262 (2^63 / 10^9 / 86400 / 365.25  292 years from 1970)
- The conversion logic in `rte_pcapng_write_packets()` correctly handles both cases

### Backwards compatibility
The patch notes that ABI version changes in 26.11, so no old symbol is kept. This is appropriate for a non-LTS release with an API parameter addition.

All existing call sites are updated to pass `0` for the timestamp parameter, maintaining previous behavior.

Review-Result: CLEAN