5 ms·

Real-time, low latency, network-based applications. At the pace of network events, CPU is still very fast by perhaps at least order of magnitude. However, late

• z3t4 7y ago
  Wouldn't virtualization kill the perf benefit, or is this supposed to run "on the metal"?
  • rusk 7y ago
    I think that depends ... I'm not an expert on virtualisation but I've seen some cases where VMs get full bare-metal access to system functions, albeit supervised. I think this is the purpose of virtualisation extensions on modern architectures (e.g. VT-x) - this is how it's possible to have a 64-bit OS run virtualised on a 64-bit processor. EDIT - but even without this, the comparison with user-space holds.
  • gjulianm 7y ago
    I don't know about other devices, but network cards have pretty good support for virtualization. A lot of them have virtual devices that the card generates and are added to the system as if they were different PCI devices. Then, each VM gets one of those virtual devices and they access it directly as a regular PCI device, with no virtualization layer whatsoever.
  • nickysielicki 7y ago
    It’s a VM in the JIT sense, not a VM in the VMWare sense.
  • zymhan 7y ago
    Virtualized OSes can still access network hardware directly via SR-IOV
• ignoramous 7y ago
  > Principally it's monitoring and "observability" applications, but apparently it's much more flexible now than it has been historically ... Yep: Here's a bredangregg presentation on the topic: https://www.youtube-nocookie.com/embed/7pmXdG8-7WU https://www.youtube-nocookie.com/embed/7pmXdG8-7WU
  • justusthane 7y ago
    That's exactly what the linked article is.
• jancsika 7y ago
  To get the realtime benefits I'd have to run everything that requires realtime scheduling as an eBPF program, right? I mean, suppose I want to make an eBPF program to pipe audio input into my very fancy DSP algo. Awesome. But now I've limited the remainder of my signal chain to remain in eBPF land, haven't I? The moment I throw the signal to Supercollider, Pd, some Jack client, etc., I'm back to being a mere userland mortal and taking the performance hit that entails. (Unless I sample that data coming into userland at a lower rate, but that severely limits the use cases for such a design.) Judging by some of the screenshots I've seen Linux audio users seem to want to mix their samples through every single audio program they can get their hands on. So at least in this domain I have a hard time seeing how eBPF could practically help realtime scheduling. Edit: clarification
  • rusk 7y ago
    Hm, good point. But couldn't you say the same thing about CUDA? There is an overhead involved in shunting data to and from the cores ... but the nature of the work being done, and the massive parallelism, mean the overall end-to-end volume of throughput increases dramatically. I don't know enough about audio processing to answer your specific question ... but processing network traffic for instance, you have the opportunity to "do things" with traffic. For instance partially decode PDUs to see if they interest you, and then pass them on to user-land for more in-depth processing if so ... EDIT I think you're thinking in terms exclusively of `mapping` operations, but this kind of thing can be great for `reducing` or filtering.
    • PaulDavisThe1st 7y ago
      There's bandwidth and there's latency. CUDA has the bandwidth, but not the latency, for generalizable low latency audio processing.
      • jancsika 7y ago
        It could still be considered low latency by adding the constraint that all use cases are in the category of call-and-response musical forms. :)
• dbancajas 7y ago
  Could you allocate a memory dynamically inside your BPF program?
  • base0x10 7y ago
    no* BPF programs are written in a very small subset of C (or rust or C++), which does not include dynamic memory allocation or unbounded loops. * you can use maps which are persistent key-value stores provided by the eBPF runtime, and you can call out to approved C functions provided by the kernel, but those won't allocate memory for you.
• the8472 7y ago
  > However, latency introduced by system calls is significant. io_uring was introduced to attack this too and essentially is an async, queue-based, batched syscall interface eliminating a lot of that latency overhead. With polling mode you only have to do a syscall when both the application and the kernel are out of work.
• waste_monk 7y ago
  > Real-time, low latency, network-based applications. I thought these kinds of applications generally (try to) avoid the kernel entirely e.g. high frequency trading algorithms running on FPGAs. Maybe using it to get data on/off of the FPGA for charting / updates / etc.