From: Marat Khalili <marat.khalili@huawei.com>
To: 苏赛 <susai.ss@bytedance.com>,
"jasvinder.singh@intel.com" <jasvinder.singh@intel.com>
Cc: "dev@dpdk.org" <dev@dpdk.org>
Subject: RE: [PATCH] net/cksum: compute raw cksum for several segments
Date: Thu, 31 Jul 2025 10:51:34 +0000 [thread overview]
Message-ID: <2b98417ad1da4df2ac4e577b9c3938ae@huawei.com> (raw)
In-Reply-To: <CABsP7wOFAsE2-BmnHZW1c3rOkkrUWfox7qrbim6zmP6gbmJqzg@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 3313 bytes --]
Hi! Thanks for submitting this. Some inline comments follow.
> -----Original Message-----
> From: 苏赛 <susai.ss@bytedance.com>
> Sent: Thursday 31 July 2025 10:55
> To: jasvinder.singh@intel.com
> Cc: dev@dpdk.org
> Subject: [PATCH] net/cksum: compute raw cksum for several segments
>
> The rte_raw_cksum_mbuf function is used to compute
> the raw checksum of a packet.
> If the packet payload stored in multi mbuf, the function
> will goto the hard case. In hard case,
> the variable 'tmp' is a type of uint32_t,
> so rte_bswap16 will drop high 16 bit.
> Meanwhile, the variable 'sum' is a type of uint32_t,
> so 'sum += tmp' will drop the carry when overflow.
> Both drop will make cksum incorrect.
> This commit fixes the above bug.
>
> Signed-off-by: Su Sai <susai.ss@bytedance.com>
> diff --git a/lib/net/rte_cksum.h b/lib/net/rte_cksum.h
> index a8e8927952..aa584d5f8d 100644
> --- a/lib/net/rte_cksum.h
> +++ b/lib/net/rte_cksum.h
> @@ -80,6 +80,25 @@ __rte_raw_cksum_reduce(uint32_t sum)
> return (uint16_t)sum;
> }
>
> +/**
> + * @internal Reduce a sum to the non-complemented checksum.
> + * Helper routine for the rte_raw_cksum_mbuf().
> + *
> + * @param sum
> + * Value of the sum.
> + * @return
> + * The non-complemented checksum.
> + */
> +static inline uint16_t
> +__rte_raw_cksum_reduce_u64(uint64_t sum)
> +{
> + uint32_t tmp;
> +
> + tmp = __rte_raw_cksum_reduce((uint32_t)sum);
> + tmp += __rte_raw_cksum_reduce((uint32_t)(sum >> 32));
What if this addition overflows?
To my taste I would not try to call `__rte_raw_cksum_reduce ` and instead reduce uint64_t directly to uint16_t, but it’s up to you.
> + return __rte_raw_cksum_reduce(tmp);
> +}
> +
> /**
> * Process the non-complemented checksum of a buffer.
> *
> @@ -119,8 +138,9 @@ rte_raw_cksum_mbuf(const struct rte_mbuf *m, uint32_t off, uint32_t len,
> {
> const struct rte_mbuf *seg;
> const char *buf;
> - uint32_t sum, tmp;
> + uint32_t tmp;
> uint32_t seglen, done;
> + uint64_t sum;
>
> /* easy case: all data in the first segment */
> if (off + len <= rte_pktmbuf_data_len(m)) {
> @@ -157,7 +177,7 @@ rte_raw_cksum_mbuf(const struct rte_mbuf *m, uint32_t off, uint32_t len,
> for (;;) {
> tmp = __rte_raw_cksum(buf, seglen, 0);
> if (done & 1)
> - tmp = rte_bswap16((uint16_t)tmp);
> + tmp = rte_bswap32(tmp);
This part probably deserves a comment, since we only need to swap odd and even bytes, but we instead reverse all of them abusing the fact that order of 2-byte pairs does not matter for the algorithm.
> sum += tmp;
> done += seglen;
> if (done == len)
> @@ -169,7 +189,7 @@ rte_raw_cksum_mbuf(const struct rte_mbuf *m, uint32_t off, uint32_t len,
> seglen = len - done;
> }
>
> - *cksum = __rte_raw_cksum_reduce(sum);
> + *cksum = __rte_raw_cksum_reduce_u64(sum);
> return 0;
> }
Changes to this function look correct to my eye, but given how many pitfalls we have already found I think we need tests.
[-- Attachment #2: Type: text/html, Size: 10523 bytes --]
next prev parent reply other threads:[~2025-07-31 10:51 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-07-31 9:55 [PATCH] net/cksum: compute raw cksum for several segments 苏赛
2025-07-31 10:51 ` Marat Khalili [this message]
2025-07-31 11:03 ` Marat Khalili
2025-07-31 11:31 ` [External] " Su Sai
2025-07-31 11:43 ` Marat Khalili
2025-07-31 11:46 ` Marat Khalili
2025-07-31 12:22 ` zhoumin
2025-08-01 7:26 ` Su Sai
2025-08-01 15:28 ` [v2] " Su Sai
2025-08-01 16:39 ` Marat Khalili
2025-08-02 11:08 ` [v3] " Su Sai
2025-08-03 16:08 ` Stephen Hemminger
2025-08-04 3:54 ` Su Sai
2025-08-05 8:55 ` Marat Khalili
2026-02-20 15:49 ` Marat Khalili
2026-02-20 17:23 ` Thomas Monjalon
2026-02-20 18:17 ` Marat Khalili
2026-02-20 18:35 ` Marat Khalili
2026-02-27 6:36 ` su sai
2026-02-27 7:31 ` su sai
2026-03-06 15:17 ` Marat Khalili
2025-08-11 14:42 ` Thomas Monjalon
2025-08-12 3:03 ` su sai
2026-02-20 17:49 ` Stephen Hemminger
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=2b98417ad1da4df2ac4e577b9c3938ae@huawei.com \
--to=marat.khalili@huawei.com \
--cc=dev@dpdk.org \
--cc=jasvinder.singh@intel.com \
--cc=susai.ss@bytedance.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.