fbc9da5dbe
fine when a lot of different flows to be ciphered/deciphered are involved. However, when a software crypto driver is used, there are situations where we could benefit from making crypto(9) multi threaded: - a single flow is to be ciphered: only one thread is used to cipher it, - a single ESP flow is to be deciphered: only one thread is used to decipher it. The idea here is to call crypto(9) using a new mode (CRYPTO_F_ASYNC) to dispatch the crypto jobs on multiple threads, if the underlying crypto driver is working in synchronous mode. Another flag is added (CRYPTO_F_ASYNC_KEEPORDER) to make crypto(9) dispatch the crypto jobs in the order they are received (an additional queue/thread is used), so that the packets are reinjected in the network using the same order they were posted. A new sysctl net.inet.ipsec.async_crypto can be used to activate this new behavior (disabled by default). Submitted by: Emeric Poupon <emeric.poupon@stormshield.eu> Reviewed by: ae, jmg, jhb Differential Revision: https://reviews.freebsd.org/D10680 Sponsored by: Stormshield |
||
---|---|---|
.. | ||
cast.c | ||
cast.h | ||
castsb.h | ||
criov.c | ||
crypto.c | ||
cryptodeflate.c | ||
cryptodev_if.m | ||
cryptodev.c | ||
cryptodev.h | ||
cryptosoft.c | ||
cryptosoft.h | ||
deflate.h | ||
gfmult.c | ||
gfmult.h | ||
gmac.c | ||
gmac.h | ||
rmd160.c | ||
rmd160.h | ||
skipjack.c | ||
skipjack.h | ||
xform_aes_icm.c | ||
xform_aes_xts.c | ||
xform_auth.h | ||
xform_blf.c | ||
xform_cast5.c | ||
xform_cml.c | ||
xform_comp.h | ||
xform_deflate.c | ||
xform_des1.c | ||
xform_des3.c | ||
xform_enc.h | ||
xform_gmac.c | ||
xform_md5.c | ||
xform_null.c | ||
xform_rijndael.c | ||
xform_rmd160.c | ||
xform_sha1.c | ||
xform_sha2.c | ||
xform_skipjack.c | ||
xform_userland.h | ||
xform.c | ||
xform.h |