YGGverse/aquatic
1
0
Fork 0
mirror of https://github.com/YGGverse/aquatic.git synced 2026-03-31 17:55:36 +00:00
Code Issues Projects Releases Packages Wiki Activity Actions

Update TODO

Browse source
This commit is contained in:
Joakim Frostegård 2024-02-09 01:23:52 +01:00
parent c980c23ffc
commit 1dcdd4f688
1 changed files with 8 additions and 27 deletions
Download patch file Download diff file Expand all files Collapse all files

35
TODO.md
View file

@ -18,14 +18,6 @@
* aquatic_ws * aquatic_ws
* Add cleaning task for ConnectionHandle.announced_info_hashes? * Add cleaning task for ConnectionHandle.announced_info_hashes?
* Performance hyperoptimization (receive interrupts on correct core)
* If there is no network card RSS support, do eBPF XDP CpuMap redirect based on packet info, to
cpus where socket workers run. Support is work in progress in the larger Rust eBPF
implementations, but exists in rebpf
* Pin socket workers
* Set SO_INCOMING_CPU (which should be fixed in very recent Linux?) to currently pinned thread
* How does this relate to (currently unused) so_attach_reuseport_cbpf code?
## Low priority ## Low priority
* aquatic_udp * aquatic_udp
@ -34,9 +26,14 @@
* thiserror? * thiserror?
* CI * CI
* uring load test? * uring load test?
* load test
* move additional request sending to for each received response, maybe * Performance hyperoptimization (receive interrupts on correct core)
with probability 0.2 * If there is no network card RSS support, do eBPF XDP CpuMap redirect based on packet info, to
cpus where socket workers run. Support is work in progress in the larger Rust eBPF
implementations, but exists in rebpf
* Pin socket workers
* Set SO_INCOMING_CPU (which should be fixed in very recent Linux?) to currently pinned thread
* How does this relate to (currently unused) so_attach_reuseport_cbpf code?
# Not important # Not important
@ -47,19 +44,3 @@
* scrape: does it work (serialization etc), and with multiple hashes? * scrape: does it work (serialization etc), and with multiple hashes?
* 'left' optional in magnet requests? Probably not. Transmission sends huge * 'left' optional in magnet requests? Probably not. Transmission sends huge
positive number. positive number.
# Don't do
* general: PGO didn't seem to help way back
## aquatic_http
* request from path:
* deserialize 20 bytes: possibly rewrite (just check length of underlying
bytes == 20 and then copy them), also maybe remove String from map for
these cases too. doesn't really improve performance
* crazy http parsing: check for newline with memchr, take slice until
there. then iter over space newlines/just take relevant data. Not faster
than httparse and a lot worse
## aquatic_udp_protocol
* Use `bytes` crate: seems to worsen performance somewhat