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 27706A00C5; Fri, 8 Jul 2022 16:10:36 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 06D53406B4; Fri, 8 Jul 2022 16:10:36 +0200 (CEST) Received: from mga03.intel.com (mga03.intel.com [134.134.136.65]) by mails.dpdk.org (Postfix) with ESMTP id 13E9B4021E; Fri, 8 Jul 2022 16:10:33 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1657289434; x=1688825434; h=date:from:to:cc:subject:message-id:references: mime-version:content-transfer-encoding:in-reply-to; bh=5weGUdbeRQyNj+3B3fdicjOZHn2AqtVPyc0lijw7m1U=; b=Da3VZr5Lblou5VReA3CjAwGzzQJJJg0DKFQuido9LrfnG3KLHIuAqOsx 21EKjEKNXzCegtjqHKxiOLfFjP/SQ8o7ZKjD5iKbpccHC1yobxpwEnHTd S5RGBKIfM4txW4XD1T0+8LPMYxj5llnHYHBN3lEEXSxmLc78/t9OVvI5k oLap0TBxxUvU2C1Z9T7oPDX2obOcyn9lF5deDQYb/PPHzl/tngX9Geu3V 6l3tWnfVgUDNb5qVmxv2g69x/wK4E2mDUGZUYyZ9oHeitBLP8CNzMrsYd Y+irU5qSQ4v+vaX2Rxs9fGntyDTj/SE4dJgHYPXP4aJV4vRsz2fc4/cPL g==; X-IronPort-AV: E=McAfee;i="6400,9594,10401"; a="285416343" X-IronPort-AV: E=Sophos;i="5.92,255,1650956400"; d="scan'208";a="285416343" Received: from orsmga003.jf.intel.com ([10.7.209.27]) by orsmga103.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 08 Jul 2022 07:10:33 -0700 X-IronPort-AV: E=Sophos;i="5.92,255,1650956400"; d="scan'208";a="544218541" Received: from bricha3-mobl.ger.corp.intel.com ([10.55.133.37]) by orsmga003-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-SHA; 08 Jul 2022 07:10:30 -0700 Date: Fri, 8 Jul 2022 15:10:27 +0100 From: Bruce Richardson To: Mattias =?iso-8859-1?Q?R=F6nnblom?= Cc: Morten =?iso-8859-1?Q?Br=F8rup?= , Mattias =?iso-8859-1?Q?R=F6nnblom?= , "olivier.matz@6wind.com" , Emil Berg , "stephen@networkplumber.org" , "stable@dpdk.org" , "bugzilla@dpdk.org" , "dev@dpdk.org" , Onar Olsen Subject: Re: [PATCH 2/2] net: have checksum routines accept unaligned data Message-ID: References: <98CBD80474FA8B44BF855DF32C47DC35D87189@smartserver.smartshare.dk> <20220707183450.3203361-1-hofors@lysator.liu.se> <20220707183450.3203361-2-hofors@lysator.liu.se> <98CBD80474FA8B44BF855DF32C47DC35D871B1@smartserver.smartshare.dk> <6839721a-8050-0e11-0c66-0f735ec8c56d@ericsson.com> <98CBD80474FA8B44BF855DF32C47DC35D871B4@smartserver.smartshare.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: 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 Fri, Jul 08, 2022 at 01:52:12PM +0000, Mattias Rönnblom wrote: > On 2022-07-08 15:02, Morten Brørup wrote: > >> From: Mattias Rönnblom [mailto:mattias.ronnblom@ericsson.com] > >> Sent: Friday, 8 July 2022 14.44 > >> > >> On 2022-07-07 23:44, Morten Brørup wrote: > >>>> From: Mattias Rönnblom [mailto:hofors@lysator.liu.se] > >>>> Sent: Thursday, 7 July 2022 20.35 > >>>> > >>>> From: Mattias Rönnblom > >>>> > >>>> __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 > >>>> > >>>> Signed-off-by: Mattias Rönnblom > >>>> --- > >>>> lib/net/rte_ip.h | 19 ++++++++++++------- > >>>> 1 file changed, 12 insertions(+), 7 deletions(-) > >>>> > >>>> diff --git a/lib/net/rte_ip.h b/lib/net/rte_ip.h > >>>> index b502481670..a9e6251f14 100644 > >>>> --- a/lib/net/rte_ip.h > >>>> +++ b/lib/net/rte_ip.h > >>>> @@ -160,18 +160,23 @@ rte_ipv4_hdr_len(const struct rte_ipv4_hdr > >>>> *ipv4_hdr) > >>>> static inline uint32_t > >>>> __rte_raw_cksum(const void *buf, size_t len, uint32_t sum) > >>>> { > >>>> - /* extend strict-aliasing rules */ > >>>> - typedef uint16_t __attribute__((__may_alias__)) u16_p; > >>>> - const u16_p *u16_buf = (const u16_p *)buf; > >>>> - const u16_p *end = u16_buf + len / sizeof(*u16_buf); > >>>> + const void *end; > >>> > >>> I would set "end" here instead, possibly making the pointer const > >> too. And add spaces around '/'. > >>> const void * const end = RTE_PTR_ADD(buf, (len / sizeof(uint16_t)) * > >> sizeof(uint16_t)); > >>> > >> > >> I don't think that makes the code more readable. > > > > It's only a matter of taste... Your code, your decision. :-) > > > > I think the spaces are required by the coding standard; not sure, though. > > > > If it isn't in the coding standard, it should be. But if you add spaces, > you have to break the line, to fit into 80 characters. A net loss, IMO. > Just FYI, lines up to 100 chars are ok now. Automated checkpatch checks as shown in patchwork only flag lines longer than that. /Bruce