summaryrefslogtreecommitdiff
path: root/sys/lib
diff options
context:
space:
mode:
authorriastradh <riastradh@NetBSD.org>2020-09-07 01:15:25 +0000
committerriastradh <riastradh@NetBSD.org>2020-09-07 01:15:25 +0000
commit59b33cb57ca29bc61af3d8a4f334f37e754f0fbf (patch)
tree8007558f83e4613213d7e80e797f65dc721aec64 /sys/lib
parente199919dc373ed13b98a69cff34b85a31dd36adf (diff)
wg: Use threadpool(9) and workqueue(9) for asynchronous tasks.
- Using threadpool(9) job per interface to receive incoming handshake messages gives the same concurrency for active interfaces but doesn't waste kthreads for inactive ones. => Can't really do this with a global workqueue(9) because there's no bound on the amount of time wg_receive_packets() might run for; we really need separate threads or threadpool jobs in order to avoid having one interface starve all the others. - Using a global workqueue(9) for asynchronous peer tasks avoids creating unnecessary kthreads. => Each task does a more or less bounded amount of work, so it's OK to share a global workqueue -- there's no advantage to adding concurrency for what is almost certainly going to be CPU-bound asymmetric crypto. => This way we don't need a thread per peer or iteration over a list of all peers, so the task mechanism should no longer be a bottleneck to scaling to thousands of peers. XXX This doesn't distribute the load across CPUs -- it keeps it on the same CPU where the packet came in. Should consider doing something to balance the load -- maybe note if the current CPU is loaded, and if so, sort CPUs by queue length or some other measure of load and pick the least loaded one or something.
Diffstat (limited to 'sys/lib')
0 files changed, 0 insertions, 0 deletions