From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <dev-bounces@dpdk.org> Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id E4B10A09E4; Sat, 5 Dec 2020 06:48:37 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 501402E81; Sat, 5 Dec 2020 06:48:36 +0100 (CET) Received: from smtp-fw-9102.amazon.com (smtp-fw-9102.amazon.com [207.171.184.29]) by dpdk.org (Postfix) with ESMTP id EC7732C58 for <dev@dpdk.org>; Sat, 5 Dec 2020 06:48:33 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amazon.com; i=@amazon.com; q=dns/txt; s=amazon201209; t=1607147314; x=1638683314; h=to:cc:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding:subject; bh=BaabL8teosHoHyQB8LkGR8SA2FcY9HYPShpvdtOX32c=; b=dX+9GREyMx8ql+ArJDrUCGRn84Wry6mMIuzAltmbGWJ90yrEb6SWTAyU CpYkh1FKO6FOpTEGu+j5UJ35spXGMZoOEvOgz/7zQRVGlr6QbNiQuxAkB MZkhGC8upDZx6so0aWri7FhKCHYzIH2QrV6ys+Jcc6rYFCffj2fRtTNaC g=; X-IronPort-AV: E=Sophos;i="5.78,394,1599523200"; d="scan'208";a="101943074" Received: from sea32-co-svc-lb4-vlan3.sea.corp.amazon.com (HELO email-inbound-relay-2a-69849ee2.us-west-2.amazon.com) ([10.47.23.38]) by smtp-border-fw-out-9102.sea19.amazon.com with ESMTP; 05 Dec 2020 05:48:32 +0000 Received: from EX13MTAUWB001.ant.amazon.com (pdx1-ws-svc-p6-lb9-vlan2.pdx.amazon.com [10.236.137.194]) by email-inbound-relay-2a-69849ee2.us-west-2.amazon.com (Postfix) with ESMTPS id D3AB6A056E; Sat, 5 Dec 2020 05:48:31 +0000 (UTC) Received: from EX13D12UWC001.ant.amazon.com (10.43.162.78) by EX13MTAUWB001.ant.amazon.com (10.43.161.249) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Sat, 5 Dec 2020 05:48:31 +0000 Received: from [192.168.2.87] (10.43.162.144) by EX13D12UWC001.ant.amazon.com (10.43.162.78) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Sat, 5 Dec 2020 05:48:30 +0000 To: Ferruh Yigit <ferruh.yigit@intel.com>, Wenzhuo Lu <wenzhuo.lu@intel.com>, Beilei Xing <beilei.xing@intel.com>, Bernard Iremonger <bernard.iremonger@intel.com> CC: <dev@dpdk.org> References: <20201203135954.1127-1-prekageo@amazon.com> <4d9e5925-8439-330c-cb27-aac64878fc24@intel.com> From: George Prekas <prekageo@amazon.com> Message-ID: <1475e52a-7801-60f8-d246-7bc9e786e95e@amazon.com> Date: Fri, 4 Dec 2020 23:47:39 -0600 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.5.1 MIME-Version: 1.0 In-Reply-To: <4d9e5925-8439-330c-cb27-aac64878fc24@intel.com> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-Originating-IP: [10.43.162.144] X-ClientProxiedBy: EX13D36UWB002.ant.amazon.com (10.43.161.149) To EX13D12UWC001.ant.amazon.com (10.43.162.78) Subject: Re: [dpdk-dev] [PATCH] app/testpmd: fix IP checksum calculation X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions <dev.dpdk.org> List-Unsubscribe: <https://mails.dpdk.org/options/dev>, <mailto:dev-request@dpdk.org?subject=unsubscribe> List-Archive: <http://mails.dpdk.org/archives/dev/> List-Post: <mailto:dev@dpdk.org> List-Help: <mailto:dev-request@dpdk.org?subject=help> List-Subscribe: <https://mails.dpdk.org/listinfo/dev>, <mailto:dev-request@dpdk.org?subject=subscribe> Errors-To: dev-bounces@dpdk.org Sender: "dev" <dev-bounces@dpdk.org> On 12/4/2020 2:59 AM, Ferruh Yigit wrote: > CAUTION: This email originated from outside of the organization. Do > not click links or open attachments unless you can confirm the sender > and know the content is safe. > > > > On 12/3/2020 1:59 PM, George Prekas wrote: >> Insert a compiler barrier to make sure that the IP checksum calculation >> happens after setting all the fields of the IP header. >> > > Can you please provide the compiler details, and if there is any specific > instruction on how to reproduce this failure? This happens with GCC 9 and GCC 10. It works fine on GCC 8. Stephen was right that a compiler barrier here is not the right solution. After spending some time on it, I realized that it is an aliasing problem when casting the IP header to uint16_t*. As far as I understand, this is not allowed by the C standard. As far as I know, there are 3 ways to fix this problem: Use a union, use memcpy, or set the compiler flag -fno-strict-aliasing. I assume that the last option is the least intrusive. I've submitted a second version of the patch with it. Let me know of your opinion. > >> Signed-off-by: George Prekas <prekageo@amazon.com> >> --- >> app/test-pmd/flowgen.c | 1 + >> 1 file changed, 1 insertion(+) >> >> diff --git a/app/test-pmd/flowgen.c b/app/test-pmd/flowgen.c >> index acf3e2460..893b4b0b8 100644 >> --- a/app/test-pmd/flowgen.c >> +++ b/app/test-pmd/flowgen.c >> @@ -150,6 +150,7 @@ pkt_burst_flow_gen(struct fwd_stream *fs) >> next_flow); >> ip_hdr->total_length = RTE_CPU_TO_BE_16(pkt_size - >> sizeof(*eth_hdr)); >> + rte_compiler_barrier(); >> ip_hdr->hdr_checksum = ip_sum((unaligned_uint16_t >> *)ip_hdr, >> sizeof(*ip_hdr)); >> >> >