The reason why I say this is that it means that instead of doing poll syscall, then get event, then issue new syscall, you can simply issue the recv. As data becomes available, it's consumed as soon as the app runs. No extra round trips, no thread offload. Win/win Now 4x faster!https://twitter.com/axboe/status/1229486613857591296 …
-
-
Replying to @axboe
It definitely is cool! One thing I'm wondering is if it's somehow possible to avoid needing one buffer for each socket? Doesn't matter for my current uses, but when handling a *lot* of connections that can be a problem.
3 replies 0 retweets 1 like -
Replying to @AndresFreundTec
I wrote about that the other day, but tldr is that I think we can do something cool there with bpf and buffer selection. If none are free, then defer.
1 reply 0 retweets 2 likes -
-
Replying to @AndresFreundTec
Right here I think. No details yet, just hand waving about how I think we should use bpf to make this possible. Because I agree it’s a sane (and common) use case. We’ll discuss at lsfmm in April.
1 reply 0 retweets 0 likes -
Replying to @axboe @AndresFreundTec
Jens Axboe Retweeted Jens Axboe
https://twitter.com/axboe/status/1229170974072791041?s=21 …https://twitter.com/axboe/status/1229170974072791041 …
Jens Axboe added,
Jens Axboe @axboeReplying to @carllercheSeems for that case that a polled approach would work the best. In the future, once we have BPF support, we might be able to do something cool that has a pool of buffers and we select a free one (and tell you about it). If none are free, request could be deferred until one is.1 reply 0 retweets 0 likes
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.