[HN Gopher] Case Study: ByteDance Uses eBPF to Enhance Networkin...
       ___________________________________________________________________
        
       Case Study: ByteDance Uses eBPF to Enhance Networking Performance
        
       Author : ChrisArchitect
       Score  : 81 points
       Date   : 2025-01-29 15:58 UTC (7 hours ago)
        
 (HTM) web link (ebpf.foundation)
 (TXT) w3m dump (ebpf.foundation)
        
       | erulabs wrote:
       | I'd love to see a more complete picture of ByteDance's TikTok
       | infra. They released "KubeAdmiral" (1) so I'm assuming they're
       | using eBPF via a Kubernetes CNI, and I see ByteDance listed on
       | Cilium's github (2). They're also using KubeRay (3) to
       | orchestrate huge inference tasks. It's annoying that a company I
       | definitely do not want to work for has such an incredibly
       | interesting infrastructure!
       | 
       | 1. https://github.com/kubewharf/kubeadmiral
       | 
       | 2. https://github.com/cilium/cilium/blob/main/USERS.md
       | 
       | 3. https://www.anyscale.com/blog/how-bytedance-scales-
       | offline-i...
        
         | koakuma-chan wrote:
         | They also made monoio, an io-uring based async runtime for
         | Rust: https://github.com/bytedance/monoio
        
         | ddxv wrote:
         | Here's my list of the decompiled apps tools and business SDKs
         | they are using:
         | 
         | https://appgoblin.info/apps/com.zhiliaoapp.musically/sdks
        
       | tptacek wrote:
       | Netkit, which is what this is built on, is pretty neat. For
       | transmitting packets from one container/VM to another, the
       | conventional solution is to give each its own veth device. When
       | you do that, the kernel network stack, at like the broad logic
       | level, is sort of oblivious to the fact that the devices aren't
       | real ethernet devices and don't have to go through the ethernet
       | motions to transact.
       | 
       | Netkit replaces that logic with a simple pairing of sending and
       | receiving eBPF programs; it's an eBPF cut-through for packet-
       | level networking between networks that share a host kernel. It's
       | faster, and it's simpler to reason about; the netkit.c code is
       | pretty easy to read straight through.
        
         | akamaka wrote:
         | Thanks for the clear explanation!
        
         | charleslmunger wrote:
         | >When you do that, the kernel network stack, at like the broad
         | logic level, is sort of oblivious to the fact that the devices
         | aren't real ethernet devices and don't have to go through the
         | ethernet motions to transact.
         | 
         | Is that true even for virtio-net? I guess I just assumed all
         | these virtual devices worked like virtiofs and had low overhead
         | fast paths for host and guest communication.
        
         | lsnd-95 wrote:
         | It would be nice to see an implementation of TCP fusion (on
         | Solaris) or SIO_LOOPBACK_FASTPATH (on Windows) for Linux.
        
       | nighthawk454 wrote:
       | > eBPF is a technology that can run programs in a privileged
       | context such as the operating system kernel. It is the successor
       | to the Berkeley Packet Filter (BPF, with the "e" originally
       | meaning "extended") filtering mechanism in Linux and is also used
       | in non-networking parts of the Linux kernel as well.
       | 
       | > It is used to safely and efficiently extend the capabilities of
       | the kernel at runtime without requiring changes to kernel source
       | code or loading kernel modules. Safety is provided through an in-
       | kernel verifier which performs static code analysis and rejects
       | programs which crash, hang or otherwise interfere with the kernel
       | negatively.
       | 
       | https://en.wikipedia.org/wiki/EBPF?useskin=vector
        
       ___________________________________________________________________
       (page generated 2025-01-29 23:00 UTC)