All of lore.kernel.org
 help / color / mirror / Atom feed
From: Olivier Matz <olivier.matz@6wind.com>
To: "Morten Brørup" <mb@smartsharesystems.com>
Cc: guohongzhi <guohongzhi1@huawei.com>,
	dev@dpdk.org, konstantin.ananyev@intel.com, jiayu.hu@intel.com,
	ferruh.yigit@intel.com, nicolas.chautru@intel.com,
	cristian.dumitrescu@intel.com, zhoujingbin@huawei.com,
	chenchanghu@huawei.com, jerry.lilijun@huawei.com,
	haifeng.lin@huawei.com, stable@dpdk.org
Subject: Re: [dpdk-dev] [PATCH] lib/librte_net: fix bug for ipv4 checksumcalculating
Date: Thu, 14 May 2020 16:19:33 +0200	[thread overview]
Message-ID: <20200514141933.GE1739@platinum> (raw)
In-Reply-To: <98CBD80474FA8B44BF855DF32C47DC35C60FC4@smartserver.smartshare.dk>

Hi,

On Thu, May 14, 2020 at 02:56:41PM +0200, Morten Brørup wrote:
> > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of guohongzhi
> > Sent: Thursday, May 14, 2020 3:27 AM
> > 
> > The function of rte_ipv4_cksum for calculating the
> > checksum of IPv4 header is incorrect.
> > This function will return checksum value like 0xffff.
> > This value, however, is considered an illegal checksum on some
> > switches(like Trident3).
> > 
> > RFC 1624 specifies the IPv4 checksum as follows:
> > https://tools.ietf.org/rfc/rfc1624
> > Since there is guaranteed to be at least one
> >    non-zero field in the IP header, and the checksum field in the
> >    protocol header is the complement of the sum, the checksum field can
> >    never contain ~(+0), which is -0 (0xFFFF).  It can, however, contain
> >    ~(-0), which is +0 (0x0000).
> > 
> > ---
> >  lib/librte_net/rte_ip.h | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/lib/librte_net/rte_ip.h b/lib/librte_net/rte_ip.h
> > index 1ceb7b7..ece2e43 100644
> > --- a/lib/librte_net/rte_ip.h
> > +++ b/lib/librte_net/rte_ip.h
> > @@ -267,7 +267,7 @@ rte_ipv4_cksum(const struct rte_ipv4_hdr *ipv4_hdr)
> >  {
> >  	uint16_t cksum;
> >  	cksum = rte_raw_cksum(ipv4_hdr, sizeof(struct rte_ipv4_hdr));
> > -	return (cksum == 0xffff) ? cksum : (uint16_t)~cksum;
> > +	return (uint16_t)~cksum;
> >  }
> > 
> >  /**
> > --
> > 2.21.0.windows.1
> > 
> > 
> 
> Well spotted!

Indeed.

> Reviewed-By: Morten Brørup <mb@smartsharesystems.com>

Fixes: 6006818cfb26 ("net: new checksum functions")
Cc: stable@dpdk.org

Acked-by: Olivier Matz <olivier.matz@6wind.com>

> Would you consider writing another patch splitting
> rte_ipv4_udptcp_cksum() up into rte_ipv4_udp_cksum() and
> rte_ipv4_tcp_cksum(), so the TCP checksum will be calculated
> correctly?
> 
> RFC 768 for UDP specifies:
> 
> If the computed checksum is zero, it is transmitted as all ones (the
> equivalent in one's complement arithmetic).  An all zero transmitted
> checksum value means that the transmitter generated no checksum (for
> debugging or for higher level protocols that don't care).
>
> RFC 793 for TCP has no such special treatment for the checksum of
> zero, but rte_ipv4_udptcp_cksum() implements the UDP special treatment
> anyway.

I agree the following test is useless in case of TCPv4 and TCPv6:

	if (cksum == 0)
                cksum =	0xffff;

For UDPv4, it is needed because 0 means "no checksum".
For UDPv6, it is needed because 0 is forbidden.

So yes, I think we could have specific csum functions for tcp and udp
checksum as Morten suggests (as soon as we keep the backward compat).

  reply	other threads:[~2020-05-14 14:19 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-14  1:27 [dpdk-dev] [PATCH] lib/librte_net: fix bug for ipv4 checksum calculating guohongzhi
2020-05-14 12:56 ` [dpdk-dev] [PATCH] lib/librte_net: fix bug for ipv4 checksumcalculating Morten Brørup
2020-05-14 14:19   ` Olivier Matz [this message]
2020-05-15  1:04   ` guohongzhi (A)
2020-05-15 10:03     ` Morten Brørup
2020-05-24 15:22 ` [dpdk-dev] [PATCH] lib/librte_net: fix bug for ipv4 checksum calculating Thomas Monjalon

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=20200514141933.GE1739@platinum \
    --to=olivier.matz@6wind.com \
    --cc=chenchanghu@huawei.com \
    --cc=cristian.dumitrescu@intel.com \
    --cc=dev@dpdk.org \
    --cc=ferruh.yigit@intel.com \
    --cc=guohongzhi1@huawei.com \
    --cc=haifeng.lin@huawei.com \
    --cc=jerry.lilijun@huawei.com \
    --cc=jiayu.hu@intel.com \
    --cc=konstantin.ananyev@intel.com \
    --cc=mb@smartsharesystems.com \
    --cc=nicolas.chautru@intel.com \
    --cc=stable@dpdk.org \
    --cc=zhoujingbin@huawei.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.