On Fri, Jan 9, 2026 at 4:26 AM Morten Brørup <[email protected]> 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.
