[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
RFC: make cryptoret() of opencrypto softint
Currently, cryptoret() which dequeues from crp_ret_q and calls crp's
callback function is done in kthread context.
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
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
Could you comment my concept or this patch?
By the way, does anyone knows why cryptoret() must be done in kthread
Internet Initiative Japan Inc.
Device Engineering Section,
IoT Platform Development Department,
Kengo NAKAHARA <k-nakahara%iij.ad.jp@localhost>
Main Index |
Thread Index |