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: dev@dpdk.org, Keith Wiles <keith.wiles@intel.com>,
	Hongzhi Guo <guohongzhi1@huawei.com>,
	Thomas Monjalon <thomas@monjalon.net>
Subject: Re: [dpdk-dev] [PATCH 3/4] net: introduce functions to verify L4 checksums
Date: Wed, 28 Apr 2021 14:21:53 +0200	[thread overview]
Message-ID: <20210428122153.GU1726@platinum> (raw)
In-Reply-To: <98CBD80474FA8B44BF855DF32C47DC35C61718@smartserver.smartshare.dk>

Hi Morten,

Thank you for the review.

<...>

On Tue, Apr 27, 2021 at 05:07:04PM +0200, Morten Brørup wrote:
> > +static inline uint16_t
> > +rte_ipv4_udptcp_cksum(const struct rte_ipv4_hdr *ipv4_hdr, const void
> > *l4_hdr)
> > +{
> > +	uint16_t cksum = __rte_ipv4_udptcp_cksum(ipv4_hdr, l4_hdr);
> > +
> > +	cksum = ~cksum;
> > +
> >  	/*
> > -	 * Per RFC 768:If the computed checksum is zero for UDP,
> > +	 * Per RFC 768: If the computed checksum is zero for UDP,
> >  	 * it is transmitted as all ones
> >  	 * (the equivalent in one's complement arithmetic).
> >  	 */
> >  	if (cksum == 0 && ipv4_hdr->next_proto_id == IPPROTO_UDP)
> >  		cksum = 0xffff;
> > 
> > -	return (uint16_t)cksum;
> > +	return cksum;
> > +}
> 
> The GCC static branch predictor treats the above comparison as likely. Playing around with Godbolt, I came up with this alternative:
> 
> 	if (likely(cksum != 0)) return cksum;
> 	if (ipv4_hdr->next_proto_id == IPPROTO_UDP) return 0xffff;
> 	return 0;

Good idea, this is indeed an unlikely branch.
However this code was already present before this patch,
so I suggest to add it as a specific optimization patch.

> > +
> > +/**
> > + * Validate the IPv4 UDP or TCP checksum.
> > + *
> > + * @param ipv4_hdr
> > + *   The pointer to the contiguous IPv4 header.
> > + * @param l4_hdr
> > + *   The pointer to the beginning of the L4 header.
> > + * @return
> > + *   Return 0 if the checksum is correct, else -1.
> > + */
> > +__rte_experimental
> > +static inline int
> > +rte_ipv4_udptcp_cksum_verify(const struct rte_ipv4_hdr *ipv4_hdr,
> > +			     const void *l4_hdr)
> > +{
> > +	uint16_t cksum = __rte_ipv4_udptcp_cksum(ipv4_hdr, l4_hdr);
> > +
> > +	if (cksum != 0xffff)
> > +		return -1;
> 
> The GCC static branch predictor treats the above comparison as likely, so I would prefer unlikely() around it.

For this one, I'm less convinced: should we decide here whether
the good or the bad checksum is more likely than the other?

Given it's a static inline function, wouldn't it be better to let
the application call it this way:
  if (likely(rte_ipv4_udptcp_cksum_verify(...) == 0))  ?


Regards,
Olivier

  reply	other threads:[~2021-04-28 12:21 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-04-27 13:57 [dpdk-dev] [PATCH 0/4] net/tap: fix Rx cksum Olivier Matz
2021-04-27 13:57 ` [dpdk-dev] [PATCH 1/4] net/tap: fix Rx cksum flags on IP options packets Olivier Matz
2021-04-30 14:48   ` [dpdk-dev] [dpdk-stable] " Ferruh Yigit
2021-06-08 10:13     ` Andrew Rybchenko
2021-06-08 12:29       ` Olivier Matz
2021-06-08 12:34         ` Andrew Rybchenko
2021-06-08 12:49           ` Olivier Matz
2021-06-08 13:57             ` Andrew Rybchenko
2021-06-08 14:30               ` Olivier Matz
2021-04-27 13:57 ` [dpdk-dev] [PATCH 2/4] net/tap: fix Rx cksum flags on TCP packets Olivier Matz
2021-06-08 10:18   ` Andrew Rybchenko
2021-04-27 13:57 ` [dpdk-dev] [PATCH 3/4] net: introduce functions to verify L4 checksums Olivier Matz
2021-04-27 15:02   ` Morten Brørup
2021-04-27 15:07   ` Morten Brørup
2021-04-28 12:21     ` Olivier Matz [this message]
2021-04-28 12:42       ` Morten Brørup
2021-04-30 15:42   ` Ferruh Yigit
2021-06-08 10:23     ` Andrew Rybchenko
2021-06-08 12:29       ` Olivier Matz
2021-06-08 12:39         ` Andrew Rybchenko
2021-06-25 15:38           ` Ferruh Yigit
2021-04-27 13:57 ` [dpdk-dev] [PATCH 4/4] test/cksum: new test for L3/L4 checksum API Olivier Matz
2021-06-30 13:51 ` [dpdk-dev] [PATCH v2 0/4] net/tap: fix Rx cksum Olivier Matz
2021-06-30 13:51   ` [dpdk-dev] [PATCH v2 1/4] net/tap: fix Rx cksum flags on IP options packets Olivier Matz
2021-06-30 13:51   ` [dpdk-dev] [PATCH v2 2/4] net/tap: fix Rx cksum flags on TCP packets Olivier Matz
2021-06-30 13:51   ` [dpdk-dev] [PATCH v2 3/4] net: introduce functions to verify L4 checksums Olivier Matz
2021-06-30 13:51   ` [dpdk-dev] [PATCH v2 4/4] test/cksum: new test for L3/L4 checksum API Olivier Matz
2021-07-01  9:28   ` [dpdk-dev] [PATCH v2 0/4] net/tap: fix Rx cksum Andrew Rybchenko

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=20210428122153.GU1726@platinum \
    --to=olivier.matz@6wind.com \
    --cc=dev@dpdk.org \
    --cc=guohongzhi1@huawei.com \
    --cc=keith.wiles@intel.com \
    --cc=mb@smartsharesystems.com \
    --cc=thomas@monjalon.net \
    /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.