Re: [RFC] alpha: optimize ip_fast_csum for BWX-capable CPUs

On Mon, Apr 20, 2026 at 1:44 AM Mike Hlavac <[email protected]> wrote:
>
> On Alpha EV56 and later, we can use the 'ldwu' instruction to significantly accelerate IP header checksumming. By manually unrolling the loop for the common 20-byte (ihl=5) case, we eliminate branch penalties and allow the compiler to optimally schedule instructions for the EV56 pipeline.
>
> Benchmarked on EV56 (Miata) at 633MHz:
>
>         • Legacy Path: 0.796s
>
>         • Unrolled BWX Path: 0.508s (~36% improvement)
>
> Tested with GCC 15. The unrolled C implementation results in straight-line assembly with no branches in the hot path.  I’d love some feedback from someone with an EV6+
>

Mike,

Thanks for working on this.  I tested the benchmark here with GCC
15.2.1 at -O2 on several CPU targets.  There does seem to be a real
optimization opportunity, but I do not think this patch is the right
shape yet.

Results here (EV67 833 MHz system) were roughly:

  ev4:  legacy ~0.365s, modern ~0.83s,  unrolled ~0.230s
  ev5:  legacy ~0.394s, modern ~0.716s, unrolled ~0.230s
  ev56: legacy ~0.304s, modern ~0.304s, unrolled ~0.171s
  ev6:  legacy ~0.314s, modern ~0.313s, unrolled ~0.177s

The measured win comes from the manually unrolled ihl==5 case becoming
straight-line code with no inner loop branch, not from the "modern C"
rewrite by itself.  On ev56/ev6, the looped legacy and looped modern-C
variants compile to essentially the same code, while on ev4/ev5 the
plain uint16_t loop is actually much worse than legacy.

One caveat is that the benchmark repeatedly checksums the same small
static header, so it mainly measures code shape with hot data.  That
is useful, but it does not say much by itself about the end-to-end
gain on real traffic. Touching old and stable code is alway a risk to
introduce new problems.

I also think the interface change is a problem.  Today Alpha has an
out-of-line ip_fast_csum() symbol.  This patch turns it into a header
inline and makes the fallback path call do_csum(), but do_csum() is
not exported, which looks wrong for modules.

The optimization itself does not seem out of line; other archs also
treat ip_fast_csum() as a specialized IPv4-header routine.  What
would seem safer here would be to keep the Alpha-specific fast path
behind the existing ip_fast_csum() implementation, with the current
checksum code as the fallback for larger ihl values and non-BWX
friendly builds.

Thanks,
Magnus