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 Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id DB1C3C25B76 for ; Wed, 5 Jun 2024 19:14:29 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=WqbdpjtKM6UX4I5Xy0aiJZrWPO1U60npOnArRHpFt1k=; b=Jtxwe6UD/A8MHf EeXIH8Je5WzNdbgm+3pzos2ek/Ix+IZB2UduL2qkyvRvluqG6+tX+zUYlt9QOLtNVAmWPGoGHWp/i 5CRuQfhCrGJE6YN7eG3/+/zvYiuqCJy9IAqP5rSM5QR9QMfAq/4MeiPB8VQPg+j+TfNke+XFjFKos YJoOgkvBUIK0o2VUsDsOq5bwYkjs9M0Sn/5JGNqrJzNphL8l0x5uQh7tiHrWt16UUOtffSryaWLv8 iEhSoJPlXHk1VATZM5nEixPRjqsvhMNnetEgmda0rtC/VLZvp9L7mrQJcg15Cf5nB5U6o6WCZrhlo vX8N/MrMk3XSu7U11oQA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1sEw5Q-00000007HT9-1DTp; Wed, 05 Jun 2024 19:14:16 +0000 Received: from dfw.source.kernel.org ([2604:1380:4641:c500::1]) by bombadil.infradead.org with esmtps (Exim 4.97.1 #2 (Red Hat Linux)) id 1sEw5N-00000007HSO-13aI for linux-arm-kernel@lists.infradead.org; Wed, 05 Jun 2024 19:14:14 +0000 Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id 6B4AC61917; Wed, 5 Jun 2024 19:14:12 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id BFE59C2BD11; Wed, 5 Jun 2024 19:14:11 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1717614852; bh=anJCOkwW/JCOoSR2rAINEuJ0OMo6WwM1LrBeDLnzJ+k=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=PmNAZJkqpGyH6vjNz47hE1ihjyXMSZTKTyoxMHhsiKfjXaljY0BTR417ondXgtokP 0jKANCFz07Dmgf+Vky5fYkDRhoxj8uCoebggx0Z8Q1djaJknCIvsfjINlfF9dy85CE 6WW38NV01bsMeRVwzeqQo3cDuSZyjB927EtHkUXwIndbI+rh5+RO6JDC16fwnR5SKg hglKztyr1w/MqT5KmbdkXB4ozoW6HFvVCGSt0a0whfigTl20B3QGWYiasLzizdsBtI zkX5Nznmb2/svFBIuTCUL4023Hl8en/suEUqcR2P8Cp0Sk0Z20RAO32FQkjeTnByMz zsTjoIXuPhmFw== Date: Wed, 5 Jun 2024 12:14:10 -0700 From: Eric Biggers To: Herbert Xu Cc: Steffen Klassert , netdev@vger.kernel.org, linux-crypto@vger.kernel.org, fsverity@lists.linux.dev, dm-devel@lists.linux.dev, x86@kernel.org, linux-arm-kernel@lists.infradead.org, Ard Biesheuvel , Sami Tolvanen , Bart Van Assche Subject: Re: [PATCH v4 6/8] fsverity: improve performance by using multibuffer hashing Message-ID: <20240605191410.GB1222@sol.localdomain> References: <20240603183731.108986-1-ebiggers@kernel.org> <20240603183731.108986-7-ebiggers@kernel.org> <20240604184220.GC1566@sol.localdomain> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240605_121413_533473_EBAFC53C X-CRM114-Status: GOOD ( 24.71 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Wed, Jun 05, 2024 at 05:46:27PM +0800, Herbert Xu wrote: > On Wed, Jun 05, 2024 at 05:22:21PM +0800, Herbert Xu wrote: > > > > However, I really dislike the idea of shoehorning this into shash. > > I know you really like shash, but I think there are some clear > > benefits to be had by coupling this with ahash. > > If we do this properly, we should be able to immediately use the > mb code with IPsec. In the network stack, we already aggregate > the data prior to IPsec with GSO. So at the boundary between > IPsec and the Crypto API, it's dividing chunks of data up to 64K > into 1500-byte packets and feeding them to crypto one at a time. > > It really should be sending the whole chain of packets to us as > a unit. > > Once we have a proper mb interface, we can fix that and immediately > get the benefit of mb hashing. > This would at most apply to AH, not to ESP. Is AH commonly used these days? Also even for AH, the IPsec code would need to be significantly restructured to make use of multibuffer hashing. See how the segmentation happens in xfrm_output_gso(), but the ahash calls happen much lower in the stack. I'm guessing that you've had the AH use case in mind since your earlier comments. Given you were originally pushing for this to be supported using the existing async support in the ahash API (which would have required fewer code changes on the AH side), but we now agree that is not feasible, maybe it is time to reconsider whether it would still be worthwhile to make all the changes to the AH code needed to support this? Also, even if it would be worthwhile and would use ahash, ahash is almost always just a wrapper for shash. So the shash support would be needed anyway. - Eric _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel