Re: [PATCH v11] net: optimize raw checksum computation

[Scott Mitchell <scott.k.mitch1@gmail.com>]

On Fri, Jan 9, 2026 at 4:26 AM Morten Brørup <mb@smartsharesystems.com> wrote:
>
> > Changes in v8:
> > - __rte_raw_cksum: use native pointer arithmetic instead of RTE_PTR_ADD
> >   to avoid incorrect results with -O3 for UDP checksums. Also improves
> >   performance due to less assembly generated with Clang.
>
> Personally, I also have observed GCC's optimizer behave as if it loses some contextual information when using RTE_PTR_ADD, and thus emitting less optimal code.
> I didn't look further into it, and thus have no data or examples to back up the claim. Which is why I haven't started a discussion about discouraging the use of RTE_PTR_ADD.
> In other words: I support this change.

Sounds good! I observed ~600 (dpdk ptr macros) vs ~500 (native c ptr
operations) TSC cycles/block in cksum_perf_autotest.

>
> >       /* if length is odd, keeping it byte order independent */
> > -     if (unlikely(len % 2)) {
> > +     if (len & 1) {
> >               uint16_t left = 0;
> > -
> >               memcpy(&left, end, 1);
> >               sum += left;
> >       }
>
> Changing "len % 2" to "len & 1" made sense for consistency in previous versions handling 32/16/8/4/2-byte chunks before this 1-byte chunk; now it makes no difference, so consider not changing this part at all.
> Under all circumstances, don't remove the unlikely() for handling odd length in __rte_raw_cksum(). The vast majority of packets (and partial packets, e.g. headers) being checksummed are even length.
>

Sounds good. I will restore the original.

The use case that motivated these changes was software interfaces (veth)
with encapsulation requiring software checksum on inner IPv4 payloads,
where lengths may be odd/even. However, I agree that header checksums
with even lengths are the more common case and unlikely() is appropriate.