<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Thu, Jun 11, 2026 at 10:36 PM Stephen Hemminger <<a href="mailto:stephen@networkplumber.org">stephen@networkplumber.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Tue,  9 Jun 2026 13:27:12 +0530<br>
Shreesh Adiga <<a href="mailto:16567adigashreesh@gmail.com" target="_blank">16567adigashreesh@gmail.com</a>> wrote:<br>
<br>
> Add a 64-byte loop that maintains 4 fold registers and processes<br>
> 64 bytes at a time. The 4x fold registers is then reduced to 16 byte<br>
> single fold, similar to AVX512 implementation. This technique is<br>
> described in the paper by Intel:<br>
> "Fast CRC Computation for Generic Polynomials Using PCLMULQDQ Instruction"<br>
> <br>
> This results in roughly 50% performance improvement due to better ILP<br>
> for large input sizes like 1024.<br>
> <br>
> Signed-off-by: Shreesh Adiga <<a href="mailto:16567adigashreesh@gmail.com" target="_blank">16567adigashreesh@gmail.com</a>><br>
> ---<br>
<br>
Looks good applied to next-net.<br>
<br>
A couple of nits from more detailed AI review, that you still might want to look at:<br>
<br>
The current crc_autotest does not exercise the new 64-byte CRC16 path.<br>
Its CRC32 vectors are 1512 and 348 bytes, so the CRC32 4x loop is<br>
covered — but the largest CRC16 vector is 32 bytes, all three CRC16<br>
tests being ≤32. So the new CRC16 rk1_rk2 (64-byte fold) constants ship<br>
untested in CI. My exhaustive test confirms they're correct, but a<br>
future regression there wouldn't be caught. Suggest adding a CRC16<br>
vector ≥64 bytes, ideally a non-multiple of 64 (e.g. 80 or 100) so it<br>
hits the 4x loop, the single-fold tail, and the partial-bytes path<br>
together.<br>
<br>
In partial_bytes the comment /* k = rk1 & rk2 */ is now stale<br>
 — after the patch k holds rk3_rk4 on every path reaching it.<br>
Not introduced by this patch, but the patch is what made it wrong;<br>
worth fixing in passing.<br>
<br></blockquote><div>I've submitted couple of follow up patches that should address the above:</div><div><a href="https://patches.dpdk.org/project/dpdk/patch/20260612023745.275608-1-16567adigashreesh@gmail.com/">https://patches.dpdk.org/project/dpdk/patch/20260612023745.275608-1-16567adigashreesh@gmail.com/</a></div><div><a href="https://patches.dpdk.org/project/dpdk/patch/20260612025135.298226-1-16567adigashreesh@gmail.com/">https://patches.dpdk.org/project/dpdk/patch/20260612025135.298226-1-16567adigashreesh@gmail.com/</a> </div></div></div>