tech-kern archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

RFC: make cryptoret() of opencrypto softint



Hi,

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?


Thanks,

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

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

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


Home | Main Index | Thread Index | Old Index