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 9A486C27C65 for ; Tue, 11 Jun 2024 20:32:37 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:List-Subscribe:List-Help :List-Post:List-Archive:List-Unsubscribe:List-Id:In-Reply-To:Content-Type: MIME-Version:References:Message-ID:Subject:Cc:To:From:Date:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=LpD99CgrJgGRYUTF75cNSbd9uM+bW6YmMhRbbeCBMSM=; b=26zZ/KqGE81BCZ6yc3nezLQ1wi P1wcF+KpQDbvzYo/TP8XA1QRaT7eMzOzPCIMKIBXxzSI1m9FsWUTzDNQOBzC+4PzeS/KNU9iv+aA7 ugJMQCFKKNMeewKQ0kLg07avwzhpoWs6te32Z6LigODLNLl2tSzbCUw5e6pkrrTD6dr5MRxl2hAjI WQQkzeLilDJ0qIMQ/KrveEB/eddiea7syaS3g66MMtCh/sUgip5CTiRmT9G0+ssSGGVjXU9R8wHT3 UtweHWS/CH0m9gXKoHhsKtluzTusurpYW69b2ZlYo3PV+dePBdVHdlc5n2jLzUQ+zBwLs9NU4cqBd WmAShXbA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1sH8AE-0000000AB9Z-3cjh; Tue, 11 Jun 2024 20:32:18 +0000 Received: from sin.source.kernel.org ([145.40.73.55]) by bombadil.infradead.org with esmtps (Exim 4.97.1 #2 (Red Hat Linux)) id 1sH8AA-0000000AB8m-3mL2 for linux-arm-kernel@lists.infradead.org; Tue, 11 Jun 2024 20:32:16 +0000 Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by sin.source.kernel.org (Postfix) with ESMTP id 6AFD8CE10F6; Tue, 11 Jun 2024 20:32:12 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 5C199C2BD10; Tue, 11 Jun 2024 20:32:11 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1718137931; bh=G8ObqV4GF1j+oexJE9NDUI3l/V6Cek7aJDyNu1zlm9o=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=ITi6r1cQKPeOmmodbECro67RGdiyNgpUQXFCIr/0smWwsxuIYn9Xy4mw4YVBstr9m gwOXW+aMNgxwWKlPP3+G7lJ+uUb6R6Ucy3ApqkiEJN1oAK+sq3Kht4M1HN9dtJJD/L vHfWynXI/OKQrluEnLQ5WrdUqadNP7RaNR9mu66RgaKT8ZDlR5u6fuKUEOgbmIeKFS F9QYV9+98uh94NzcPP8cwSBa3MGFfZr6RiMwvCP57VdC3YgllZyLZx+EiNJPx2gfgu 7F1ZhKmfa2Bs3gUR0ckol1DgXS6LR86VGjwjo0d6lPWJe+N82YwApaSHld/JO9UIXX aYjWziC/8YcTA== Date: Tue, 11 Jun 2024 13:32:09 -0700 From: Eric Biggers To: Herbert Xu Cc: Ard Biesheuvel , 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, Sami Tolvanen , Bart Van Assche , Tim Chen Subject: Re: [PATCH v4 6/8] fsverity: improve performance by using multibuffer hashing Message-ID: <20240611203209.GB128642@sol.localdomain> References: <20240610164258.GA3269@sol.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240611_133215_484816_9B6B7B9E X-CRM114-Status: GOOD ( 16.62 ) 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: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Tue, Jun 11, 2024 at 11:39:08PM +0800, Herbert Xu wrote: > On Tue, Jun 11, 2024 at 11:21:43PM +0800, Herbert Xu wrote: > > > > Therefore if we switched to a linked-list API networking could > > give us the buffers with minimal changes. > > BTW, this is not just about parallelising hashing. Just as one of > the most significant benefits of GSO does not come from hardware > offload, but rather the amortisation of (network) stack overhead. > IOW you're traversing a very deep stack once instead of 40 times > (this is the factor for 64K vs MTU, if we extend beyond 64K (which > we absolute should do) the benefit would increase as well). > > The same should apply to the Crypto API. So even if this was a > purely software solution with no assembly code at all, it may well > improve GCM performance (at least for users able to feed us bulk > data, like networking). > At best this would save an indirect call per message, if the underlying algorithm explicitly added support for it and the user of the API migrated to the multi-request model. This alone doesn't seem worth the effort of migrating to multi-request, especially considering the many other already-possible optimizations that would not require API changes or migrating users to multi-request. The x86_64 AES-GCM is pretty well optimized now after my recent patches, but there's still an indirect call associated with the use of the SIMD helper which could be eliminated, saving one per message (already as much as we could hope to get from multi-request). authenc on the other hand is almost totally unoptimized, as I mentioned before; it makes little sense to talk about any sort of multi-request optimization for it at this point. - Eric