DPDK patches and discussions
 help / color / mirror / Atom feed
From: Andrew Rybchenko <arybchenko@solarflare.com>
To: "Ananyev, Konstantin" <konstantin.ananyev@intel.com>,
	Ivan Malov <ivan.malov@oktetlabs.ru>,
	Olivier Matz <olivier.matz@6wind.com>
Cc: "dev@dpdk.org" <dev@dpdk.org>,
	"Kulasek, TomaszX" <tomaszx.kulasek@intel.com>,
	"stable@dpdk.org" <stable@dpdk.org>
Subject: Re: [dpdk-dev] [PATCH] net: fix the way how L4 checksum choice is tested
Date: Mon, 24 Jun 2019 15:16:41 +0300	[thread overview]
Message-ID: <fe91340b-e5a5-c1c5-caee-2ef5f31aa079@solarflare.com> (raw)
In-Reply-To: <2601191342CEEE43887BDE71AB97725801689E3F36@IRSMSX104.ger.corp.intel.com>

On 6/24/19 3:01 PM, Ananyev, Konstantin wrote:
>
>> -----Original Message-----
>> From: Ananyev, Konstantin
>> Sent: Monday, June 24, 2019 12:52 PM
>> To: 'Ivan Malov' <ivan.malov@oktetlabs.ru>; Olivier Matz <olivier.matz@6wind.com>
>> Cc: dev@dpdk.org; Kulasek, TomaszX <tomaszx.kulasek@intel.com>; stable@dpdk.org
>> Subject: RE: [dpdk-dev] [PATCH] net: fix the way how L4 checksum choice is tested
>>
>>
>>> The API to prepare checksum offloads mistreats L4
>>> checksum type enum values as self-contained flags.
>>>
>>> Turning these flag checks into enum checks causes
>>> warnings by GCC about possibly uninitialised IPv4
>>> header pointer. The issue was found to show up in
>>> the case of GCC versions 4.8.5 and 5.4.0, however,
>>> it might be the case for a wider variety of other
>>> versions. As GCC version 7.4.0 is not susceptible
>>> to the said false positive assessment, this patch
>>> maintains a compiler barrier for earlier versions.
>>>
>>> Fixes: 4fb7e803eb1a ("ethdev: add Tx preparation")
>>> Cc: Tomasz Kulasek <tomaszx.kulasek@intel.com>
>>> Cc: stable@dpdk.org
>>>
>>> Signed-off-by: Ivan Malov <ivan.malov@oktetlabs.ru>
>>> ---
>>>   lib/librte_net/rte_net.h | 16 ++++++++++++++--
>>>   1 file changed, 14 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/lib/librte_net/rte_net.h b/lib/librte_net/rte_net.h
>>> index 7088584..fb09431 100644
>>> --- a/lib/librte_net/rte_net.h
>>> +++ b/lib/librte_net/rte_net.h
>>> @@ -151,7 +151,19 @@ uint32_t rte_net_get_ptype(const struct rte_mbuf *m,
>>>   			ipv4_hdr->hdr_checksum = 0;
>>>   	}
>>>
>> As I remember, saw something similar before...
>> Probably the eaiser way to overcome it, is just to always initialize ipv4_hdr above,
>> something like:
>>
>> +ipv4_hdr = NULL;
>> if (ol_flags & PKT_TX_IPV4) {
>>                  ipv4_hdr = rte_pktmbuf_mtod_offset(m, struct rte_ipv4_hdr *,
>>                                  inner_l3_offset);
>>
>>                  if (ol_flags & PKT_TX_IP_CKSUM)
>>                          ipv4_hdr->hdr_checksum = 0;
>>   }
> As another possible option  always initialisze both, and then use either one or another,
> depending on flags:
>
> ipv4_hdr = rte_pktmbuf_mtod_offset(m, struct rte_ipv4_hdr *, inner_l3_offset);
> ipv6_hdr = rte_pktmbuf_mtod_offset(m, struct rte_ipv6_hdr *, inner_l3_offset);
> ....

We have discussed the solution locally and rejected it since it just kills
the compiler help. It makes it possible to use invalid header and
compiler will not save you.

Suggested solution looks ugly, but at least it does not kill help from
compiler.

>>> -	if ((ol_flags & PKT_TX_UDP_CKSUM) == PKT_TX_UDP_CKSUM) {
>>> +#ifdef GCC_VERSION
>>> +#if GCC_VERSION < 70400
>>> +	/*
>>> +	 * Earlier versions of GCC suspect access to possibly
>>> +	 * uninitialised ipv4_hdr in the code below, although
>>> +	 * the said variable is properly initialised above.
>>> +	 * Use compiler barrier to cope with the problem.
>>> +	 */
>>> +	rte_compiler_barrier();
>>> +#endif
>>> +#endif
>>> +
>>> +	if ((ol_flags & PKT_TX_L4_MASK) == PKT_TX_UDP_CKSUM) {
>>>   		if (ol_flags & PKT_TX_IPV4) {
>>>   			udp_hdr = (struct rte_udp_hdr *)((char *)ipv4_hdr +
>>>   					m->l3_len);
>>> @@ -167,7 +179,7 @@ uint32_t rte_net_get_ptype(const struct rte_mbuf *m,
>>>   			udp_hdr->dgram_cksum = rte_ipv6_phdr_cksum(ipv6_hdr,
>>>   					ol_flags);
>>>   		}
>>> -	} else if ((ol_flags & PKT_TX_TCP_CKSUM) ||
>>> +	} else if ((ol_flags & PKT_TX_L4_MASK) == PKT_TX_TCP_CKSUM ||
>>>   			(ol_flags & PKT_TX_TCP_SEG)) {
>>>   		if (ol_flags & PKT_TX_IPV4) {
>>>   			/* non-TSO tcp or TSO */
>>> --
>>> 1.8.3.1


  reply	other threads:[~2019-06-24 12:16 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-05-29 17:33 Ivan Malov
2019-06-24 11:52 ` Ananyev, Konstantin
2019-06-24 12:01 ` Ananyev, Konstantin
2019-06-24 12:16   ` Andrew Rybchenko [this message]
2019-06-27 13:26     ` Ananyev, Konstantin
2019-06-27 21:52 ` [dpdk-dev] [PATCH v2] " Ivan Malov
2019-06-28  0:10   ` Stephen Hemminger
2019-06-28  3:13 ` [dpdk-dev] [PATCH v3] " Ivan Malov
2019-06-28  4:26   ` Stephen Hemminger
2019-06-28 10:47   ` Ananyev, Konstantin
2019-06-28 16:24     ` Ferruh Yigit

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=fe91340b-e5a5-c1c5-caee-2ef5f31aa079@solarflare.com \
    --to=arybchenko@solarflare.com \
    --cc=dev@dpdk.org \
    --cc=ivan.malov@oktetlabs.ru \
    --cc=konstantin.ananyev@intel.com \
    --cc=olivier.matz@6wind.com \
    --cc=stable@dpdk.org \
    --cc=tomaszx.kulasek@intel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).