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
|
||||
|
||||
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
|
||||
|
@ -12,8 +21,6 @@ scaling and work queues:
|
|||
https://tokio.rs/blog/2019-10-scheduler
|
||||
|
||||
What we want to do is:
|
||||
* one thread per core
|
||||
* thread pinning
|
||||
* ebpf BBR packet pacing
|
||||
* need to support non-ebpf BBR for mobile ios, too
|
||||
* connection sharding
|
||||
|
|
Loading…
Reference in New Issue