From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 88074A0032; Mon, 11 Jul 2022 15:25:17 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id F12D2410DD; Mon, 11 Jul 2022 15:25:16 +0200 (CEST) Received: from mail-wm1-f49.google.com (mail-wm1-f49.google.com [209.85.128.49]) by mails.dpdk.org (Postfix) with ESMTP id ADF9240DF6 for ; Mon, 11 Jul 2022 15:25:14 +0200 (CEST) Received: by mail-wm1-f49.google.com with SMTP id i128-20020a1c3b86000000b003a2ce31b4f8so5006149wma.1 for ; Mon, 11 Jul 2022 06:25:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=6wind.com; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:content-transfer-encoding:in-reply-to; bh=BEolV0UUYPZyhJ6eItS6wcyowcKdkVxttFDEUbLL3bI=; b=FFQSGHD3axsFM7hWQbKJxclwrFd0L91O/lh1ReVLo9mtqrbLaY/AZDSdINlfXmSRyl 5ENwn2zXqMVLeBsHVqNtz4/bw59kv/NdF0TOK91UpqtuXcOq2i99N+lqQfmPgi8wmpBZ jlEcOpGK7jsEluIO8H+EgDSgjvV5okeudQe9potfC40OJn3cpeAdbtEOX3j3KE8m63Bj GU4W7Gavs0e/LMR7PyxiZLLBZ+j2xok9ghGTUebprOThKvA70B1aoljNglreyPyKidCr DzXCKaJJnPKucmocOlzsGT/a4KB1zXZ3CDn0yOUdtV1VtIUQ5NjPMGoqg6ky1LttY8te farQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to; bh=BEolV0UUYPZyhJ6eItS6wcyowcKdkVxttFDEUbLL3bI=; b=E19/fu+NH1PUY0VSPOn805aC6T84FBP2EQnepwBqejNbU+D2vggfQzh+sx6VJgFaBg wdSrPecOLRy3u9ORgEjv1/LU0QVGJaF2K6yN/P1LthBggoxzpwS0OOiHzwIyNn06PxCe mYjlFbHVLBS8bjtBLjf6y3otgMdUmUimW7yBE6GkvcXlyvqTkQv09JZbF+gixJ5zyDBE MbSaHlYk875MTHJSUuc5dJPmgOe6z6SpKe4I+b6zM5pSXNy2VSt0OnsCDAswcFCw8u4S vQQxw9WmNtxMC+1yaIAN2W8lL8qyboEfvzNMJ2jQj4Mg9QwU+/gBnGYGHYu+Day5ZFSt K79w== X-Gm-Message-State: AJIora/QEIg9iQ6QF1/tHaxu9TX3k56KZNuJrQ/uTGNQaY6/HVSmPpZq CMPlkqc7IRcFbUOqW/luuc3LHQ== X-Google-Smtp-Source: AGRyM1t0ZTPOhgAzyfHACvHZI6Z0Qwv27RsH10hY3COrUvghwmpWcxmtiGXTXszKCzuEyrrWGlkV/Q== X-Received: by 2002:a05:600c:3492:b0:3a1:70dd:9a14 with SMTP id a18-20020a05600c349200b003a170dd9a14mr15566094wmq.177.1657545914420; Mon, 11 Jul 2022 06:25:14 -0700 (PDT) Received: from 6wind.com ([2a01:e0a:5ac:6460:c065:401d:87eb:9b25]) by smtp.gmail.com with ESMTPSA id r1-20020a5d6941000000b00210bac248c8sm5871274wrw.11.2022.07.11.06.25.13 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 11 Jul 2022 06:25:13 -0700 (PDT) Date: Mon, 11 Jul 2022 15:25:13 +0200 From: Olivier Matz To: Mattias =?iso-8859-1?Q?R=F6nnblom?= Cc: Emil Berg , bruce.richardson@intel.com, stephen@networkplumber.org, stable@dpdk.org, bugzilla@dpdk.org, dev@dpdk.org, onar.olsen@ericsson.com, Morten =?iso-8859-1?Q?Br=F8rup?= Subject: Re: [PATCH v3 2/2] net: have checksum routines accept unaligned data Message-ID: References: <20220711121132.34546-1-mattias.ronnblom@ericsson.com> <20220711121132.34546-2-mattias.ronnblom@ericsson.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20220711121132.34546-2-mattias.ronnblom@ericsson.com> 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 On Mon, Jul 11, 2022 at 02:11:32PM +0200, Mattias Rönnblom wrote: > __rte_raw_cksum() (used by rte_raw_cksum() among others) accessed its > data through an uint16_t pointer, which allowed the compiler to assume > the data was 16-bit aligned. This in turn would, with certain > architectures and compiler flag combinations, result in code with SIMD > load or store instructions with restrictions on data alignment. > > This patch keeps the old algorithm, but data is read using memcpy() > instead of direct pointer access, forcing the compiler to always > generate code that handles unaligned input. The __may_alias__ GCC > attribute is no longer needed. > > The data on which the Internet checksum functions operates are almost > always 16-bit aligned, but there are exceptions. In particular, the > PDCP protocol header may (literally) have an odd size. > > Performance impact seems to range from none to a very slight > regression. > > Bugzilla ID: 1035 > Cc: stable@dpdk.org Fixes: 6006818cfb26 ("net: new checksum functions") > --- > > v3: > * Use RTE_ALIGN_FLOOR() in the pointer arithmetic (Olivier Matz). > v2: > * Simplified the odd-length conditional (Morten Brørup). > > Reviewed-by: Morten Brørup > > Signed-off-by: Mattias Rönnblom Acked-by: Olivier Matz Thank you!