4 ms·
The project has a long history of skewing the performance benchmarks and making wild claims like "60% faster than epoll" and the creator gets very defensive whe
by junon 5y ago
The project has a long history of skewing the performance benchmarks and making wild claims like "60% faster than epoll" and the creator gets very defensive when anyone questions it.
There are claims about SQPOLL that simply cannot be reproduced. Several ongoing threads about it on the liburing tracker.
There have been privilege escalation problems from the start that seem like they aren't being addressed.
It feels as though Facebook wants to have something revolutionary at the cost of quality and they're using the Linux kernel to do so, though I realize that's my own hot take.
Again, I've been following this (and writing code for it) since I could get my hands on the dev branches. It's only really good for filesystem I/O in its current form as that's the biggest focus they have for it. They (Facebook) care less about other resource types (e.g. sockets).
You can choose to believe me or not, I suppose.
- touisteur 5y agoThanks for taking the time to expand a bit more, on your experience with the code and the community around it. I'll have a look. Right now I'm more interested in the chaining aspect than raw performance but I know some of my high-throughout network workloads behave far better in latency with the complete syscall removal on recv and send though keeping up with the completion queue is hard-ish. I still prefer dpdk right now for this kind of network stuff but just because my use case is perfectly adapted for it (no fragmentation, no complex protocol, constant data stream...) and dpdk ain't no party either.