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 C583CA09FF; Thu, 7 Jan 2021 06:25:21 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id B067A140E84; Thu, 7 Jan 2021 06:25:21 +0100 (CET) Received: from mail-pg1-f182.google.com (mail-pg1-f182.google.com [209.85.215.182]) by mails.dpdk.org (Postfix) with ESMTP id 2FEEC140E80 for ; Thu, 7 Jan 2021 06:25:19 +0100 (CET) Received: by mail-pg1-f182.google.com with SMTP id n10so4041131pgl.10 for ; Wed, 06 Jan 2021 21:25:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=8enA5gxHFMtp3h1Aw5427qA3x06jyaTw5dZ3MmKEyn0=; b=kMtaPcakoSmCVpqNPMWv1AlbpjL5dPTckKWEKy6WAiirZMAHfz0VOT43FiEr0k5iC2 MmTfBaG+2IUO/alIc8GeoeJYgwof0u9uTVvk0Xh72FV9LQUqdhEAXwNvuL1MK31UdOeO F3W+6oMshYbLTPyJSXJ6YB407w9ZsbvgVoDfrg8OWOEMwycZjA25UF8zBSycTBBKp0jb WxFQKfQYHNGpQbPri/r32HITBu65qLytouN6XXTvLQ9pH7m4v5Uc96D129SctcTUVtaU agR0PtmACAXJjj/PnYVZmRPWURL+m+qQDKdQ0pCKLYpqo3hf9f8iUSbpl6nPQK3FRZX1 1ayA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=8enA5gxHFMtp3h1Aw5427qA3x06jyaTw5dZ3MmKEyn0=; b=UuvdJlXhO7+HjZChPjC5S9Vf/PS0N/wRpDXqBd+T3ANrGgB4cQYcJ9ItuCLhLgbAsw JVI/NAiwwg2/xXS7hYtWOCY+fD2zTureCLzVNCFOi2UFwBUO6/adi0qrMMeD4L7Y6N3z 0YcxmFWu4tzjwmRHcI56lVYqPe9EHstWVXd5GyjZNJUc/2oXdG6hM6n8jFjaW/qkVH3I Gzh0bKedHcRUXqhV0NQJY2t+qEYfM7TtCpS0rllRDygi3jV3NEZj9yl5Oyxi/aogOVMW M6BF/kZSimCIoIyE3b/N8JaEJeLb4YZvQLkAIIbABVGTfcpcDneJu9+CCcrvRRcoPy1M q0Yw== X-Gm-Message-State: AOAM5337z5ssvGhhTJX33n+K3/2dMLk/i7vs/3EzOKswZ+EZBL4K4D2J 1sHSf9ZA3EjMoefkHLmYL8fVXw== X-Google-Smtp-Source: ABdhPJyBmnyTx8gpPPrJPczB5gdPkpfhTr/r4+1bwzHINI6cF3hDps8hp+mrN5JsckKuPRJvCUjVYA== X-Received: by 2002:aa7:843a:0:b029:19d:b279:73c9 with SMTP id q26-20020aa7843a0000b029019db27973c9mr7443992pfn.3.1609997118442; Wed, 06 Jan 2021 21:25:18 -0800 (PST) Received: from hermes.local (204-195-22-127.wavecable.com. [204.195.22.127]) by smtp.gmail.com with ESMTPSA id b19sm4066125pfo.24.2021.01.06.21.25.17 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 06 Jan 2021 21:25:18 -0800 (PST) Date: Wed, 6 Jan 2021 21:25:04 -0800 From: Stephen Hemminger To: Ferruh Yigit Cc: George Prekas , Wenzhuo Lu , Beilei Xing , Bernard Iremonger , dev@dpdk.org Message-ID: <20210106212504.24448d9d@hermes.local> In-Reply-To: <8c1fd6ad-302d-f45e-f48a-e81fd5f8ba85@intel.com> References: <20201203135954.1127-1-prekageo@amazon.com> <20201205054238.12469-1-prekageo@amazon.com> <8c1fd6ad-302d-f45e-f48a-e81fd5f8ba85@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit 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 Wed, 6 Jan 2021 18:02:49 +0000 Ferruh Yigit wrote: > 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? If it is an aliasing problem, it should be fixed with a union instead of a compiler flag.