3 ms·
A great writeup, but just to take issue (or at least discuss) this one point: > There may be some performance penalty of shifting the transport code from the k
by quietbritishjim 4y ago
A great writeup, but just to take issue (or at least discuss) this one point:
> There may be some performance penalty of shifting the transport code from the kernel to user space
This makes it sound like a kernel has potential for slightly more optimised implementation. But I think it's more than that - the transport code can be completely offloaded from the CPU to the network card/processor. That can only happen if it's abstracted behind syscalls, not written in user space.
- jacob019 4y agoHere's a relevant discussion from 2021: https://lore.kernel.org/netdev/CAK-6q+id+CJgoSHaMGMs=d1Lr81bukrdjbszhujVEYnimtnq8w@mail.gmail.com/T/ https://lore.kernel.org/netdev/CAK-6q+id+CJgoSHaMGMs=d1Lr81b... If QUIC sees wide adoption then it's just a matter of time before the protocol starts moving up stack.
- hinkley 4y agoWhen I read about eBPF there always seems to be an implication that we could move this logic to the NIC. I don’t know enough about it to know if that’s aspirational or an active project. But the idea of being able to push code to the “right” side of bottlenecks is a running theme, including in questions of user space versus kernel space. Chatty communication kills throughout and/or latency.
- mdaverde 4y agoThe NICs I could find that enable this behavior belong to Netronome: https://www.netronome.com/products/agilio-cx/ https://www.netronome.com/products/agilio-cx/ I've been meaning to get my hand on one of these to play around with eBPF offload. There is also XDP (a subsystem of eBPF) which lets you take action before the packets run up the entire network stack.
- hinkley 4y agoI thought we had a couple options now? Well that sucks then. Netronome doesn’t print their prices. That’s not a great sign. If you have to ask, you can’t afford them.