[PATCH v7] net: optimize raw checksum computation

[Scott Mitchell]

On Thu, Jan 8, 2026 at 11:24 AM Stephen Hemminger
<stephen at networkplumber.org> wrote:
>
> On Thu,  8 Jan 2026 09:59:13 -0500
> scott.k.mitch1 at gmail.com wrote:
>
> > diff --git a/lib/net/rte_ip4.h b/lib/net/rte_ip4.h
> > index 822a660cfb..67033875cc 100644
> > --- a/lib/net/rte_ip4.h
> > +++ b/lib/net/rte_ip4.h
> > @@ -223,21 +223,19 @@ rte_ipv4_phdr_cksum(const struct rte_ipv4_hdr *ipv4_hdr, uint64_t ol_flags)
> >               uint8_t  zero;     /* zero. */
> >               uint8_t  proto;    /* L4 protocol type. */
> >               uint16_t len;      /* L4 length. */
> > -     } psd_hdr;
> > -
> > -     uint32_t l3_len;
> > -
> > -     psd_hdr.src_addr = ipv4_hdr->src_addr;
> > -     psd_hdr.dst_addr = ipv4_hdr->dst_addr;
> > -     psd_hdr.zero = 0;
> > -     psd_hdr.proto = ipv4_hdr->next_proto_id;
> > -     if (ol_flags & (RTE_MBUF_F_TX_TCP_SEG | RTE_MBUF_F_TX_UDP_SEG)) {
> > -             psd_hdr.len = 0;
> > -     } else {
> > -             l3_len = rte_be_to_cpu_16(ipv4_hdr->total_length);
> > -             psd_hdr.len = rte_cpu_to_be_16((uint16_t)(l3_len -
> > -                     rte_ipv4_hdr_len(ipv4_hdr)));
> > -     }
> > +     } psd_hdr = {
> > +             .src_addr = ipv4_hdr->src_addr,
> > +             .dst_addr = ipv4_hdr->dst_addr,
> > +             .proto = ipv4_hdr->next_proto_id,
> > +             .len = (ol_flags & (RTE_MBUF_F_TX_TCP_SEG | RTE_MBUF_F_TX_UDP_SEG)) ? 0 :
> > +                     rte_cpu_to_be_16((uint16_t)(rte_be_to_cpu_16(ipv4_hdr->total_length) -
> > +                             rte_ipv4_hdr_len(ipv4_hdr)))
> > +     };
> > +#ifdef RTE_
>
> I find it hard to read complex expressions in initialiazers.
> Much better as original if statement.
> Sometimes you need a union to convince compiler of aliasing
>

I improved the readability of the ternary in the v8 patch (coming soon).
Rational for using an initializer is to lean on the c99 spec which
guarantees the
memory is initialized. Given the ambiguity around "maybe uninitialized
variable use" I made the code in question explicit on initialization.
Let me know
if the approach in v8 patch is not inline with dpdk standards/convention and I
can rework.