Message ID | 20220711121132.34546-2-mattias.ronnblom@ericsson.com (mailing list archive) |
---|---|
State | Accepted, archived |
Delegated to: | Thomas Monjalon |
Headers |
Return-Path: <dev-bounces@dpdk.org> X-Original-To: patchwork@inbox.dpdk.org Delivered-To: patchwork@inbox.dpdk.org Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 30789A0032; Mon, 11 Jul 2022 14:14:27 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id CEECB40C35; Mon, 11 Jul 2022 14:14:26 +0200 (CEST) Received: from EUR02-VE1-obe.outbound.protection.outlook.com (mail-eopbgr20084.outbound.protection.outlook.com [40.107.2.84]) by mails.dpdk.org (Postfix) with ESMTP id EDBD440695; Mon, 11 Jul 2022 14:14:24 +0200 (CEST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=LjFgQ7yAiUr5X23h2S3x6a2ibUfJXF8bRcxdTaWq3fhvkZRYGFoqce5FUETXSn4AcJfza0AsS7Z/Q3dNMTCWFBWjuV68zT0J4DJNgof6BCCJffpjmoBTb/pSRiWPRsj0vx9q9e4egPjW+b/7cLKA7ntOJqZJRb0OeU9/KODT6BzTHAGfQE7VjKh5nOxf44EogcfB5rxoiWVT3b7yQR6LOisewO84i5f8PixTqHBmZsBcGB0POfWwiPp3ngAkOZuqXJ+JNo0lJDDk+O89T0z+PU9txe3RoAAU93NLHdvi2gPENzdg33WY7nCX0ihzoMzn4e0gR0/YrCr4+O6TqzOMWQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=4S+OiGLiOj+U3zEwgKXzjgcHgOhgFSCjIqChLmz5SNE=; b=W6uWd7tO21xI6xaGwhXSCpS85f7+61pyUGgdoKhaFWXYD67xSMvlB9rxMSPQPlzEpQ8XwlGOEAeWeVAqk3KflBVxsN+Qu8RtCa7xxRCvwzLWI2AeT59kKw3VXR+DV8l1qNYl3WH81ODVilicV3GOUGVIifmowl8jV0zVxSY412OcRZ7KamKe+oollTEUBeVo70diZAQsaGUIXAGyRQxZ1j5BIJRyfzYd9bNzxcc2XLL+EEHgcgTA2/oq5IxDkNwSIl1lETPYq5IgYPpXTuvVPdL2MymVUZXZiIjbh055om/meG3ex+8UlWqlbjZTedg0BOfy38g2PtO7GrEyTD1sBA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 192.176.1.74) smtp.rcpttodomain=6wind.com smtp.mailfrom=ericsson.com; dmarc=pass (p=reject sp=reject pct=100) action=none header.from=ericsson.com; dkim=none (message not signed); arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=4S+OiGLiOj+U3zEwgKXzjgcHgOhgFSCjIqChLmz5SNE=; b=hfdBduNo4nNgxAo57qWXlVJku+XmI2lC0jkw5sZ/S0gLIY/956Gm+PBrgHCEQ8tTwOlFPXL+33378VVSErdSW8L8DND3M3lKbKxQEZO+9+5CNXEcTreed0+EQ/k99/G5LGbF6BHTqNW4ddci0WQMuxs1vLXgPdZQpOXXKyWqEZk= Received: from AS9PR06CA0199.eurprd06.prod.outlook.com (2603:10a6:20b:45d::18) by DB9PR07MB7210.eurprd07.prod.outlook.com (2603:10a6:10:214::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5417.11; Mon, 11 Jul 2022 12:14:23 +0000 Received: from VE1EUR02FT008.eop-EUR02.prod.protection.outlook.com (2603:10a6:20b:45d:cafe::d5) by AS9PR06CA0199.outlook.office365.com (2603:10a6:20b:45d::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5417.15 via Frontend Transport; Mon, 11 Jul 2022 12:14:23 +0000 X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 192.176.1.74) smtp.mailfrom=ericsson.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=ericsson.com; Received-SPF: Pass (protection.outlook.com: domain of ericsson.com designates 192.176.1.74 as permitted sender) receiver=protection.outlook.com; client-ip=192.176.1.74; helo=oa.msg.ericsson.com; pr=C Received: from oa.msg.ericsson.com (192.176.1.74) by VE1EUR02FT008.mail.protection.outlook.com (10.152.12.72) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256) id 15.20.5417.15 via Frontend Transport; Mon, 11 Jul 2022 12:14:23 +0000 Received: from ESESBMB503.ericsson.se (153.88.183.170) by ESESSMR501.ericsson.se (153.88.183.108) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2375.28; Mon, 11 Jul 2022 14:14:22 +0200 Received: from seliicinfr00050.seli.gic.ericsson.se (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.186) with Microsoft SMTP Server id 15.1.2375.28 via Frontend Transport; Mon, 11 Jul 2022 14:14:22 +0200 Received: from localhost.localdomain (seliicwb00002.seli.gic.ericsson.se [10.156.25.100]) by seliicinfr00050.seli.gic.ericsson.se (Postfix) with ESMTP id CA9B11C0060; Mon, 11 Jul 2022 14:14:22 +0200 (CEST) From: =?utf-8?q?Mattias_R=C3=B6nnblom?= <mattias.ronnblom@ericsson.com> To: <olivier.matz@6wind.com> CC: Emil Berg <emil.berg@ericsson.com>, <bruce.richardson@intel.com>, <stephen@networkplumber.org>, <stable@dpdk.org>, <bugzilla@dpdk.org>, <dev@dpdk.org>, <onar.olsen@ericsson.com>, =?utf-8?q?Morten_Br=C3=B8rup?= <mb@smartsharesystems.com>, =?utf-8?q?Mattia?= =?utf-8?q?s_R=C3=B6nnblom?= <mattias.ronnblom@ericsson.com> Subject: [PATCH v3 2/2] net: have checksum routines accept unaligned data Date: Mon, 11 Jul 2022 14:11:32 +0200 Message-ID: <20220711121132.34546-2-mattias.ronnblom@ericsson.com> X-Mailer: git-send-email 2.25.1 In-Reply-To: <20220711121132.34546-1-mattias.ronnblom@ericsson.com> References: <YswKoLL5BCS7qvrZ@platinum> <20220711121132.34546-1-mattias.ronnblom@ericsson.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: cdceaf5c-20fc-41b2-2afe-08da6336e43c X-MS-TrafficTypeDiagnostic: DB9PR07MB7210:EE_ X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: fSXtsvkwfSSjKc3Yp5Y3mCrFwmhqPLYiOLKzrLifbLCj0yIPaqIU1eSx1k0PJZiRcUx0fMyO+8HpBI6P4gMQxdV7gDxRrWgixTt9NYgTKat+D268gJOxKjrSWL8Pjc7IYtaiGIBTdweuFeaXFO7aimyL0vnJXiSx3rLJDnUzLIchtvpAxDAf3HAIDmTHglKMLIFlUbxai3Qj8qs34RstDm4S5bsxAWDWtSLuCWW1Irr7kUmGvyCAfIYW22zFaa8gMQkkg7yyzEIAgtyJhldebdtl787AryMkL1FuTuocZDgTFR4RNNU23wlPAp1TEDsjhf024meTyG83q+7cQYXmBKXu/7FMkzIzngD3fnn5KiGcQ737cocGbO+TQZu7HhjcRpuP5TdYFQZXdzdgcWdP1w75WJNfAspzXXDX1RtNgGgqF/K9exHeW+OByhpWbSqW96bXdQcJnGJ2u2w9XO/DNVTeQZXUf51gwYYxKhlGUH8IYMldUvBtwV4YAZe+nEA5aknYAGj/1exBp3EyjfCvEDSqmN/EvE0rXJuyVlzeQ0mRvJAy18D4mKM8Q3rW8k11NJJWHvAg0QsqPa2XUSMdnIC7kWt6XF4EGlLt9nPiDCj9nXVMH+3+Lxw8PXseyHTJkQ+noq4mfhc5/6pUnLnuRH6A4/7ww5sOd4+vgXHaWNeapWdp/ybkuOnTrNRWvgcw19JnS61I27KkiNgh8/DZk66z6W3uzYqWpLcPF89CUwtyf8cpFwLVBNAnpaxsalJ7uIKfQwRL76wPsXMM7BAwFCfyFOLgMd/fvkAR8N1vn7jKDtQfd+7oFV6OvrxkkBpPAiHftABC93DIXD/OZcYPIvOpYR0dDn/jnFL10hRrk+/KwJbJLtcu0ahtX3sMUW/l X-Forefront-Antispam-Report: CIP:192.176.1.74; CTRY:SE; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:oa.msg.ericsson.com; PTR:office365.se.ericsson.net; CAT:NONE; SFS:(13230016)(4636009)(39860400002)(396003)(376002)(136003)(346002)(40470700004)(36840700001)(46966006)(83380400001)(8676002)(6916009)(478600001)(40460700003)(36860700001)(40480700001)(82960400001)(5660300002)(2906002)(4326008)(41300700001)(6666004)(356005)(8936002)(70586007)(82740400003)(26005)(70206006)(6266002)(66574015)(107886003)(47076005)(2616005)(1076003)(316002)(186003)(86362001)(82310400005)(336012)(54906003)(36756003)(7636003); DIR:OUT; SFP:1101; X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 11 Jul 2022 12:14:23.4253 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: cdceaf5c-20fc-41b2-2afe-08da6336e43c X-MS-Exchange-CrossTenant-Id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=92e84ceb-fbfd-47ab-be52-080c6b87953f; Ip=[192.176.1.74]; Helo=[oa.msg.ericsson.com] X-MS-Exchange-CrossTenant-AuthSource: VE1EUR02FT008.eop-EUR02.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB9PR07MB7210 X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 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 |
Series |
[v3,1/2] app/test: add cksum performance test
|
|
Checks
Context | Check | Description |
---|---|---|
ci/checkpatch | success | coding style OK |
ci/iol-intel-Performance | success | Performance Testing PASS |
ci/iol-intel-Functional | success | Functional Testing PASS |
ci/iol-x86_64-compile-testing | success | Testing PASS |
ci/github-robot: build | success | github build: passed |
ci/iol-aarch64-compile-testing | success | Testing PASS |
ci/iol-abi-testing | success | Testing PASS |
ci/iol-aarch64-unit-testing | success | Testing PASS |
ci/iol-x86_64-unit-testing | success | Testing PASS |
ci/Intel-compilation | success | Compilation OK |
ci/intel-Testing | success | Testing PASS |
Commit Message
Mattias Rönnblom
July 11, 2022, 12:11 p.m. UTC
__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 --- 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 <mb@smartsharesystems.com> Signed-off-by: Mattias Rönnblom <mattias.ronnblom@ericsson.com> --- lib/net/rte_ip.h | 17 ++++++++++------- 1 file changed, 10 insertions(+), 7 deletions(-)
Comments
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 <mb@smartsharesystems.com> > > Signed-off-by: Mattias Rönnblom <mattias.ronnblom@ericsson.com> Acked-by: Olivier Matz <olivier.matz@6wind.com> Thank you!
On 2022-07-11 15:25, Olivier Matz wrote: > 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 <mb@smartsharesystems.com> >> >> Signed-off-by: Mattias Rönnblom <mattias.ronnblom@ericsson.com> > > Acked-by: Olivier Matz <olivier.matz@6wind.com> > > Thank you! Will this be merged into 22.11? Into the stable branches?
On 2022-07-11 15:25, Olivier Matz wrote: > 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 <mb@smartsharesystems.com> >> >> Signed-off-by: Mattias Rönnblom <mattias.ronnblom@ericsson.com> > > Acked-by: Olivier Matz <olivier.matz@6wind.com> > > Thank you! Are there any plans to merge this patchset?
20/09/2022 14:09, Mattias Rönnblom: > On 2022-07-11 15:25, Olivier Matz wrote: > > 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 <mb@smartsharesystems.com> > >> > >> Signed-off-by: Mattias Rönnblom <mattias.ronnblom@ericsson.com> > > > > Acked-by: Olivier Matz <olivier.matz@6wind.com> > > > > Thank you! > > Are there any plans to merge this patchset? Applied, thanks. Sorry for the delay.
diff --git a/lib/net/rte_ip.h b/lib/net/rte_ip.h index b502481670..ecd250e9be 100644 --- a/lib/net/rte_ip.h +++ b/lib/net/rte_ip.h @@ -160,18 +160,21 @@ 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; - for (; u16_buf != end; ++u16_buf) - sum += *u16_buf; + for (end = RTE_PTR_ADD(buf, RTE_ALIGN_FLOOR(len, sizeof(uint16_t))); + buf != end; buf = RTE_PTR_ADD(buf, sizeof(uint16_t))) { + uint16_t v; + + memcpy(&v, buf, sizeof(uint16_t)); + sum += v; + } /* if length is odd, keeping it byte order independent */ if (unlikely(len % 2)) { uint16_t left = 0; - *(unsigned char *)&left = *(const unsigned char *)end; + + memcpy(&left, end, 1); sum += left; }