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

On Wed, Jan 20, 2016 at 12:38 AM, Herbert Xu wrote: > 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

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

On Thu, Nov 20, 2014 at 03:43:42PM +0800, Herbert Xu wrote: On Thu, Nov 20, 2014 at 08:26:51AM +0100, Steffen Klassert wrote: What about to use a fallback algorithm that does not need to touch FPU/SIMD in such cases? We would not need cryptd at all and it would keep the requests in the

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

On Thu, Nov 20, 2014 at 08:59:44AM +0100, Steffen Klassert wrote: Sure, but could be an option if this is really a rare case. Well it's rare but when it does hit it'll probably be there all the time for that system. IOW you either have no apps using the FPU, but when you do, it's probably

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

On Sat, Nov 15, 2014 at 11:15:50AM +0800, Herbert Xu wrote: On Wed, Nov 12, 2014 at 09:41:38AM +0100, Steffen Klassert wrote: Everything below the local_bh_enable() should not run in atomic context as the subsequent functions may set the CRYPTO_TFM_REQ_MAY_SLEEP flag. Actually I'm

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

On Thu, Nov 20, 2014 at 08:26:51AM +0100, Steffen Klassert wrote: What about to use a fallback algorithm that does not need to touch FPU/SIMD in such cases? We would not need cryptd at all and it would keep the requests in the right order because we don't defer them. This would be bad for

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

On Wed, Nov 12, 2014 at 09:41:38AM +0100, Steffen Klassert wrote: Everything below the local_bh_enable() should not run in atomic context as the subsequent functions may set the CRYPTO_TFM_REQ_MAY_SLEEP flag. Actually I'm thinking of doing exactly that (disabling softirq in cryptd) to fix the

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

On Wed, Nov 12, 2014 at 01:49:31PM +0800, Ming Liu wrote: So far, the encryption/decryption are asynchronously processed in softirq and cryptd which would result in a implicit order of data, therefore leads IPSec stack also out of order while encapsulating or decapsulating packets. Consider

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

On Wed, Nov 12, 2014 at 09:41:38AM +0100, Steffen Klassert wrote: Can't we just use cryptd unconditionally to fix this reordering problem? I think the idea is that most of the time cryptd isn't required so we want to stick with direct processing to lower latency. I think the simplest fix would

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

On Wed, Nov 12, 2014 at 04:51:48PM +0800, Herbert Xu wrote: On Wed, Nov 12, 2014 at 09:41:38AM +0100, Steffen Klassert wrote: Can't we just use cryptd unconditionally to fix this reordering problem? I think the idea is that most of the time cryptd isn't required so we want to stick with

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

On 11/12/2014 04:51 PM, Herbert Xu wrote: On Wed, Nov 12, 2014 at 09:41:38AM +0100, Steffen Klassert wrote: Can't we just use cryptd unconditionally to fix this reordering problem? I think the idea is that most of the time cryptd isn't required so we want to stick with direct processing to

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

On 11/12/2014 04:41 PM, Steffen Klassert wrote: On Wed, Nov 12, 2014 at 01:49:31PM +0800, Ming Liu wrote: So far, the encryption/decryption are asynchronously processed in softirq and cryptd which would result in a implicit order of data, therefore leads IPSec stack also out of order while

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

On Wed, Nov 12, 2014 at 06:41:30PM +0800, Ming Liu wrote: On 11/12/2014 04:51 PM, Herbert Xu wrote: On Wed, Nov 12, 2014 at 09:41:38AM +0100, Steffen Klassert wrote: Can't we just use cryptd unconditionally to fix this reordering problem? I think the idea is that most of the time cryptd isn't

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

On Wed, Nov 12, 2014 at 06:41:28PM +0800, Ming Liu wrote: On 11/12/2014 04:41 PM, Steffen Klassert wrote: On Wed, Nov 12, 2014 at 01:49:31PM +0800, Ming Liu wrote: } @@ -147,11 +149,9 @@ static void cryptd_queue_worker(struct work_struct *work) preempt_disable(); backlog =

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

On 11/12/2014 07:43 PM, Steffen Klassert wrote: On Wed, Nov 12, 2014 at 06:41:30PM +0800, Ming Liu wrote: On 11/12/2014 04:51 PM, Herbert Xu wrote: On Wed, Nov 12, 2014 at 09:41:38AM +0100, Steffen Klassert wrote: Can't we just use cryptd unconditionally to fix this reordering problem? I

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

So far, the encryption/decryption are asynchronously processed in softirq and cryptd which would result in a implicit order of data, therefore leads IPSec stack also out of order while encapsulating or decapsulating packets. Consider the following scenario: DECRYPTION INBOUND