From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-4.0 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_PASS autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 6DEF0C4360F for ; Thu, 28 Feb 2019 15:21:06 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 46CC8206B8 for ; Thu, 28 Feb 2019 15:21:06 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2388604AbfB1POE (ORCPT ); Thu, 28 Feb 2019 10:14:04 -0500 Received: from usa-sjc-mx-foss1.foss.arm.com ([217.140.101.70]:49690 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2388599AbfB1POD (ORCPT ); Thu, 28 Feb 2019 10:14:03 -0500 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id A1E12A78; Thu, 28 Feb 2019 07:14:02 -0800 (PST) Received: from [10.1.196.75] (e110467-lin.cambridge.arm.com [10.1.196.75]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 4449D3F720; Thu, 28 Feb 2019 07:14:01 -0800 (PST) Subject: Re: [PATCH] arm64: do_csum: implement accelerated scalar version To: Ard Biesheuvel , Ilias Apalodimas , Catalin Marinas Cc: "" , "huanglingyan (A)" , Will Deacon , linux-arm-kernel , Steve Capper References: <20190218230842.11448-1-ard.biesheuvel@linaro.org> <20190219150848.GA26652@apalos> From: Robin Murphy Message-ID: <93697477-4dcc-4ab2-c838-2f487d334c56@arm.com> Date: Thu, 28 Feb 2019 15:13:59 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org Hi Ard, On 28/02/2019 14:16, Ard Biesheuvel wrote: > (+ Catalin) > > On Tue, 19 Feb 2019 at 16:08, Ilias Apalodimas > wrote: >> >> On Tue, Feb 19, 2019 at 12:08:42AM +0100, Ard Biesheuvel wrote: >>> It turns out that the IP checksumming code is still exercised often, >>> even though one might expect that modern NICs with checksum offload >>> have no use for it. However, as Lingyan points out, there are >>> combinations of features where the network stack may still fall back >>> to software checksumming, and so it makes sense to provide an >>> optimized implementation in software as well. >>> >>> So provide an implementation of do_csum() in scalar assembler, which, >>> unlike C, gives direct access to the carry flag, making the code run >>> substantially faster. The routine uses overlapping 64 byte loads for >>> all input size > 64 bytes, in order to reduce the number of branches >>> and improve performance on cores with deep pipelines. >>> >>> On Cortex-A57, this implementation is on par with Lingyan's NEON >>> implementation, and roughly 7x as fast as the generic C code. >>> >>> Cc: "huanglingyan (A)" >>> Signed-off-by: Ard Biesheuvel > ... >> >> Acked-by: Ilias Apalodimas > > Full patch here > > https://lore.kernel.org/linux-arm-kernel/20190218230842.11448-1-ard.biesheuvel@linaro.org/ > > This was a follow-up to some discussions about Lingyan's NEON code, > CC'ed to netdev@ so people could chime in as to whether we need > accelerated checksumming code in the first place. FWIW ever since we did ip_fast_csum() I've been meaning to see how well I can do with a similar tweaked C implementation for this (mostly for fun). Since I've recently dug out my RK3328 box for other reasons I'll give this a test - that's a weedy little quad-A53 whose GbE hardware checksumming is slightly busted and has to be turned off, so the do_csum() overhead under heavy network load is comparatively massive. (plus it's non-EFI so I should be able to try big-endian easily too) The asm looks pretty reasonable to me - instinct says there's *possibly* some value for out-of-order cores in doing the 8-way accumulations in a more pairwise fashion, but I guess either way the carry flag dependency is going to dominate, so it may well be moot. What may be more worthwhile is taking the effort to align the source pointer, at least for larger inputs, so as to be kinder to little cores - according to its optimisation guide, A55 is fairly sensitive to unaligned loads, so I'd assume that's true of its older/smaller friends too. I'll see what I can measure in practice - until proven otherwise I'd have no great objection to merging this patch as-is if the need is real. Improvements can always come later :) Robin.