Re: [PATCH] crypto: aesni-intel - avoid IPsec re-ordering

Hi Herbert,

Thanks very much for your prompt replies. Please see inline..

On Tue, Jan 19, 2016 at 7:25 PM, Herbert Xu [off-list ref] wrote:

On Tue, Jan 19, 2016 at 09:39:51AM -0800, Raj Ammanur wrote:

quoted

Thanks a bunch Herbert. I will try out the patch when you make it available.


Are there any thoughts for these other questions from you or anyone
else on the list, more
importantly regarding backlog handling in ESP ?


2. When the pkts are put on the async work queue, the queue size is initialized
as 100 in cryptd_init_queue() in crypto/cryptd.c. Does anyone know how/why
100 was picked ?

This should probably be increased to match NAPI queue lengths.

RAJ: ok. would it also be useful to be able to set the length as a module
load time parameter?

quoted

3. In cryptd_queue_worker(), the backlog->complete() callback is invoked with
-EINPROGRESS. In net/ipv4/esp4.c, there is no handling for EINPROGRESS
in esp_input_done()/esp_input_done2(). Am I reading the code correctly and
is there any expectation that ESP should support backlog and have backlog
handling ? Currently, the pkt just gets dropped as the EINPROGRESS is treated
as nexthdr and hence is invalid.

IPsec does not use crypto backlogging so complete should never be
called with EINPROGRESS.  If the queue length is exceeded the
packet will be dropped.

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.

thanks
--Raj

Cheers,
--
Email: Herbert Xu [off-list ref]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt