Update architecture.md
Signed-off-by: Luca Fulchir <luca.fulchir@runesauth.com>
This commit is contained in:
parent
1259996201
commit
e581cb064a
|
@ -1,8 +1,17 @@
|
||||||
# Architecture
|
# Architecture
|
||||||
|
|
||||||
For now we will keep things as easy as possible, not caring about the performance.
|
The current architecture is based on tokio.
|
||||||
|
In the future we might want something more general purpose (and no-std),
|
||||||
|
but good enough for now.
|
||||||
|
|
||||||
This means we will use only ::tokio and spawn one job per connection
|
Tokio has its own thread pool, and we spawn one async loop per listening socket.
|
||||||
|
|
||||||
|
Then we spawn our own thread pool.
|
||||||
|
These threads are pinned to the cpu cores.
|
||||||
|
We spawn one async worker per thread, making sure it remains pinned to that core.
|
||||||
|
This is done to avoid *a lot* of locking and multithread syncronizations.
|
||||||
|
|
||||||
|
We do connection sharding on the connection id.
|
||||||
|
|
||||||
|
|
||||||
# Future
|
# Future
|
||||||
|
@ -12,8 +21,6 @@ scaling and work queues:
|
||||||
https://tokio.rs/blog/2019-10-scheduler
|
https://tokio.rs/blog/2019-10-scheduler
|
||||||
|
|
||||||
What we want to do is:
|
What we want to do is:
|
||||||
* one thread per core
|
|
||||||
* thread pinning
|
|
||||||
* ebpf BBR packet pacing
|
* ebpf BBR packet pacing
|
||||||
* need to support non-ebpf BBR for mobile ios, too
|
* need to support non-ebpf BBR for mobile ios, too
|
||||||
* connection sharding
|
* connection sharding
|
||||||
|
|
Loading…
Reference in New Issue