Re: RFC: make cryptoret() of opencrypto softint

[Kengo NAKAHARA <k-nakahara%iij.ad.jp@localhost>]

Hi,

On 2017/07/06 18:37, Kengo NAKAHARA wrote:
> Currently, cryptoret() which dequeues from crp_ret_q and calls crp's
> callback function is done in kthread context.
>     https://nxr.netbsd.org/xref/src/sys/opencrypto/crypto.c#416
> 
> In contrast, crypto_done() which enqueues to crp_ret_q is done in
> interrupt context or softint context when opencrypto(9) is used by IPsec.
> 
> This difference of context between crypto_done() and cryptoret() makes
> the length of crp_ret_q very long when IPsec puts high load. As a result,
> it causes very long latency. In worst case, the latency is a few seconds.
> In May 24, I committed crypto_ret_q limitation. This limitation can avoid
> such a long latency, however it drops many packets. Hmm, it is annoying
> trade-off...
> 
> I think the context mismatch between crypto_done()(enqueue side) and
> cryptoret()(dequeue side) causes this problem. So, I think cryptoret()
> should be done in softint context. As the callback functions both IPsec
> and /dev/crypto do not sleep, it seems there is no problem to make
> cryptoret() softint. Here is the patch
>     http://www.netbsd.org/~knakahara/cryptoret-softint/cryptoret-softint.patch
> 
> Could you comment my concept or this patch?
> By the way, does anyone knows why cryptoret() must be done in kthread
> context?

As there is no objection for about two weeks, I commit above patch with
a little improvement. Although I tested with ATF net/ and crypto/, if
you encounter a problem, please apply below reverse patch.
    http://www.netbsd.org/~knakahara/cryptoret-softint/cryptoret-softint-reverse.patch


Thanks,

-- 
//////////////////////////////////////////////////////////////////////
Internet Initiative Japan Inc.

Device Engineering Section,
IoT Platform Development Department,
Network Division,
Technology Unit

Kengo NAKAHARA <k-nakahara%iij.ad.jp@localhost>