tech-net 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