Received: by 2002:a05:6a10:f347:0:0:0:0 with SMTP id d7csp432187pxu; Tue, 1 Dec 2020 15:14:22 -0800 (PST) X-Google-Smtp-Source: ABdhPJz/xOLLRFhW0tWZAN6DeMZLZ7HVW+fQK1mAC3kmMk6xzXZu1b6HZIDwfZzPTKCW7hzEPphc X-Received: by 2002:a17:906:d8a1:: with SMTP id qc1mr5298926ejb.294.1606864462322; Tue, 01 Dec 2020 15:14:22 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1606864462; cv=none; d=google.com; s=arc-20160816; b=IE8AcZ6J0a+nqCYRAXijMt0ehIpIS8R4F2JaTFcb9Eaj/27lKvoRYzmbTrhBOETzrO OjnGuH86Km3PKLa+hb6P0ZsbwES84ZXbRH65JnveSzL14RncvB5XlfsDVpxLhlxKfE/p vBCdI+7jEiZ2vYXtvhHzo1KxD1uer45Yqr/AYhE1q0fQ/NrmK3XeIYv3VOLYFCrb8CEs SoMsRwrgHzyy7cqjLgQRlvm+d7FyFAz67m+1bQHdq/lU/Nj635Ne8P9dsS3Uc7WGOhfX sxc2iKd76Fj7RyTeqAm8qFy9bDH2lUU2zuuI1ky8MwFo21+OPIFFsLo5pg7hKwphSO+g CChA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:user-agent:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date; bh=ykv3VOEAUDEvAPnuYl4fJKIlfw920vDbNL+3NxlR5aU=; b=tqfHuC3/2jAH7etCOnsSwPTs0S4GKcCeukqyhN/0Y9XVrFUytZ2SmVMxkxSLwcUBIh /BsxF3h2yMsTUIQYHgfKRAXZphvTaLWqKaJmAoG3j+UbGOwt9gzcrioAH/4uWanrotIy h7Egye7dWlhevld7hA6aOFkYopD6lFfThChAiFGh0jLDAWT8gkvOFfoRnFLjRLvUtsvL zTMRUfa6reJvXCrPLQ7fy4bG5IeoyQpXBR3Njg6Qxlfom4l8aTrMJMX0MgmKwLIHXNxM gfJPfvkRLxM0wQtKxBy2fK2cSljf14gqa9nrNz5NSCJHd27DJR0Ykb8ec9UtpZOlb9TZ TCWw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-crypto-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-crypto-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id du15si899927ejc.471.2020.12.01.15.13.46; Tue, 01 Dec 2020 15:14:22 -0800 (PST) Received-SPF: pass (google.com: domain of linux-crypto-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-crypto-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-crypto-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726240AbgLAXMn (ORCPT + 99 others); Tue, 1 Dec 2020 18:12:43 -0500 Received: from helcar.hmeau.com ([216.24.177.18]:51466 "EHLO fornost.hmeau.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726082AbgLAXMn (ORCPT ); Tue, 1 Dec 2020 18:12:43 -0500 Received: from gwarestrin.arnor.me.apana.org.au ([192.168.0.7]) by fornost.hmeau.com with smtp (Exim 4.92 #5 (Debian)) id 1kkEoQ-00030K-CI; Wed, 02 Dec 2020 10:11:59 +1100 Received: by gwarestrin.arnor.me.apana.org.au (sSMTP sendmail emulation); Wed, 02 Dec 2020 10:11:58 +1100 Date: Wed, 2 Dec 2020 10:11:58 +1100 From: Herbert Xu To: Ard Biesheuvel Cc: Linux Crypto Mailing List , Ben Greear , Steve deRosier Subject: Re: [PATCH v2] crypto: aesni - add ccm(aes) algorithm implementation Message-ID: <20201201231158.GA32274@gondor.apana.org.au> References: <20201201194556.5220-1-ardb@kernel.org> <20201201215722.GA31941@gondor.apana.org.au> <20201201220431.GA32072@gondor.apana.org.au> <20201201221628.GA32130@gondor.apana.org.au> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Precedence: bulk List-ID: X-Mailing-List: linux-crypto@vger.kernel.org On Tue, Dec 01, 2020 at 11:27:52PM +0100, Ard Biesheuvel wrote: > > > The problem is that the degradation would come at the worst time, > > when the system is loaded. IOW when you get an interrupt during > > your TX path and get RX traffic that's when you'll take the fallback > > path. > > I can see how in the general case, this is something you would prefer > to avoid. However, on SMP x86_64 systems that implement AES-NI (which > runs at ~1 cycle per byte), I don't see this as a real problem for > this driver. AES-NI is 1 cycle per byte but the fallback is not. > What we could do is expose both versions, where the async version has > a slightly higher priority, so that all users that do support the > async interface will get it, and the wifi stack can use the sync > interface instead. No we've already tried this with IPsec and it doesn't work. That's why the async path exists in aesni. Wireless is no different to IPsec in this respect. Cheers, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt