4 ms·

Skewed performance tests? Dubious funding? I'm not sure what you mean. Can't Facebook fund any technical work? I see some reasons not to use it (like it's a vu

Skewed performance tests? Dubious funding? I'm not sure what you mean. Can't Facebook fund any technical work? I see some reasons not to use it (like it's a vulkan-like low-level-only API, or portability issues, or some missing APIs in my case-s) but 'it was funded by facebook' and 'it has security risks'? I mean I'm not sure there's an area in the kernel without corporate funding/support, or without past security bugs. We keep finding vulnerabilities in ipv6, sctp... Yes the Linux kernel dev process is lacking but likely for different symptoms & causes?

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 ago
  Thanks 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.

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 ago
Thanks 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.