diff options
| author | fabient <fabient@FreeBSD.org> | 2017-11-03 10:27:22 +0000 |
|---|---|---|
| committer | Luiz Souza <luiz@netgate.com> | 2018-01-28 16:15:43 -0200 |
| commit | 3c959029c95eb7877ae7d109e0c226c9a03d64fb (patch) | |
| tree | e77ccf3250fd4b2fe081427d2b51cbf91beea6fa /contrib/llvm/tools/clang/lib/CodeGen/CGCUDARuntime.cpp | |
| parent | fa7ab497a8798d4122e156c52ec772999ddfac9f (diff) | |
| download | FreeBSD-src-3c959029c95eb7877ae7d109e0c226c9a03d64fb.zip FreeBSD-src-3c959029c95eb7877ae7d109e0c226c9a03d64fb.tar.gz | |
crypto(9) is called from ipsec in CRYPTO_F_CBIFSYNC mode. This is working
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
(cherry picked from commit fbc9da5dbe50b72a335de7a27b6834fba8ee3cf0)
Diffstat (limited to 'contrib/llvm/tools/clang/lib/CodeGen/CGCUDARuntime.cpp')
0 files changed, 0 insertions, 0 deletions
