39bbca6ffd
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 |
||
---|---|---|
.. | ||
colldef | ||
ctypedef | ||
dict | ||
doc | ||
dtrace | ||
examples | ||
i18n | ||
keys | ||
man | ||
misc | ||
mk | ||
monetdef | ||
msgdef | ||
numericdef | ||
security | ||
sendmail | ||
skel | ||
snmp | ||
syscons | ||
tabset | ||
termcap | ||
tests | ||
timedef | ||
vt | ||
zoneinfo | ||
Makefile | ||
Makefile.inc |