From: Herbert Xu Subject: Re: [PATCH] crypto: aesni-intel - avoid IPsec re-ordering Date: Wed, 20 Jan 2016 16:38:07 +0800 Message-ID: <20160120083806.GA20214@gondor.apana.org.au> References: <20160119074343.GA7753@gondor.apana.org.au> <20160120032537.GA18992@gondor.apana.org.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: linux-crypto@vger.kernel.org To: Raj Ammanur Return-path: Received: from helcar.hengli.com.au ([209.40.204.226]:46863 "EHLO helcar.hengli.com.au" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751546AbcATIib (ORCPT ); Wed, 20 Jan 2016 03:38:31 -0500 Content-Disposition: inline In-Reply-To: Sender: linux-crypto-owner@vger.kernel.org List-ID: On Wed, Jan 20, 2016 at 12:31:46AM -0800, Raj Ammanur wrote: > > RAJ: ok. would it also be useful to be able to set the length as a module > load time parameter? That would be a bad interface. If we wanted to have an adjustable limit it needs to be set by the entity that is creating the tfm, i.e., IPsec. > RAJ: hmm, thats true, yes. > > so, is the below description, that you wrote in one of your email replies, > the solution for which you are going to create a patch? > > > So what I'm thinking of is to have the softirq path forcibly regain > > control from cryptd where possible. This is tricky because cryptd > > might be in the middle of processing a request. So that's why I'd > > like to disable softirqs while we're processing a request. Yes. Cheers, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt