From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (xvm-189-124.dc0.ghst.net [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id D68DBA09FF; Wed, 6 Jan 2021 19:03:32 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 586BB140E13; Wed, 6 Jan 2021 19:03:32 +0100 (CET) Received: from mga07.intel.com (mga07.intel.com [134.134.136.100]) by mails.dpdk.org (Postfix) with ESMTP id 98C7040FA7 for ; Wed, 6 Jan 2021 19:03:29 +0100 (CET) IronPort-SDR: 4Ye5Sg1qlbSgHDaeoovnNo7WPtuPeWJRF1WvbGo15Ml4YVBYM/v9A3ltvbvTv24xH63XPWt5jU axbslP6aOgUQ== X-IronPort-AV: E=McAfee;i="6000,8403,9856"; a="241391308" X-IronPort-AV: E=Sophos;i="5.79,327,1602572400"; d="scan'208";a="241391308" Received: from orsmga001.jf.intel.com ([10.7.209.18]) by orsmga105.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 06 Jan 2021 10:02:56 -0800 IronPort-SDR: sXkiHiZU94r3CQoU2hn9HG3rq5LgDi0/8Dr5kgdd9NH0CZHorVHIOT8zjl6ujm1Dg7xo4HXufC 2552hHMYHaLw== X-IronPort-AV: E=Sophos;i="5.79,327,1602572400"; d="scan'208";a="422251262" Received: from fyigit-mobl1.ger.corp.intel.com (HELO [10.251.93.217]) ([10.251.93.217]) by orsmga001-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 06 Jan 2021 10:02:54 -0800 To: George Prekas , Wenzhuo Lu , Beilei Xing , Bernard Iremonger Cc: dev@dpdk.org, Stephen Hemminger References: <20201203135954.1127-1-prekageo@amazon.com> <20201205054238.12469-1-prekageo@amazon.com> From: Ferruh Yigit Message-ID: <8c1fd6ad-302d-f45e-f48a-e81fd5f8ba85@intel.com> Date: Wed, 6 Jan 2021 18:02:49 +0000 MIME-Version: 1.0 In-Reply-To: <20201205054238.12469-1-prekageo@amazon.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Subject: Re: [dpdk-dev] [PATCH v2] app/testpmd: fix IP checksum calculation X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" On 12/5/2020 5:42 AM, George Prekas wrote: > Strict-aliasing rules are violated by cast to uint16_t* in flowgen.c > and the calculated IP checksum is wrong on GCC 9 and GCC 10. > > Signed-off-by: George Prekas > --- > v2: > * Instead of a compiler barrier, use a compiler flag. > --- > app/test-pmd/meson.build | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/app/test-pmd/meson.build b/app/test-pmd/meson.build > index 7e9c7bdd6..5d24e807f 100644 > --- a/app/test-pmd/meson.build > +++ b/app/test-pmd/meson.build > @@ -4,6 +4,7 @@ > # override default name to drop the hyphen > name = 'testpmd' > cflags += '-Wno-deprecated-declarations' > +cflags += '-fno-strict-aliasing' > sources = files('5tswap.c', > 'cmdline.c', > 'cmdline_flow.c', > Hi George, I am trying to understand this, the relevant code is as below: ip_hdr->hdr_checksum = ip_sum((unaligned_uint16_t *)ip_hdr, sizeof(*ip_hdr)); You are suspicious of strict aliasing rule violation, with more details: The concern is the "struct rte_ipv4_hdr *ip_hdr;" aliased to "const unaligned_uint16_t *hdr", and compiler can optimize out the calculations using data pointed by 'hdr' pointer, since the 'hdr' pointer is not used to alter the data and compiler may think data is not changed at all. 1) But the pointer "hdr" is assigned in the loop, from another pointer whose content is changing, why this is not helping to figure out that the data 'hdr' pointing is changed. 2) I tried to debug this, but I am not able to reproduce the issue, 'ip_sum()' called each time and checksum calculated correctly. Using gcc 10.2.1-9. Can you able to confirm the case with debug, or from the assembly/object file? And if the issue is strict aliasing rule violation as you said, compiler flag is an option but not sure how much it reduces the compiler optimization benefit, I guess other options also not so good, memcpy brings too much work on runtime and union requires bigger change and makes code complex. I wonder if making 'ip_sum()' a non inline function can help, can you please give a try since you can reproduce it?