Can someone explain in one simple paragraph what this is?
BPF: A New Type of Software
131–140 of 192 posts
Re: BPF: A New Type of Software
#132This is less about BPF vs native code, and more about the process model vs the event based model of application programming. Event based handling is inherently more efficient because it runs in the context of the caller, instead of requiring its own context like in process-based applications. This is the main reason why file system code in the kernel is more efficient than file system servers running in a different p…
To be fair it should be considered that within the kernel space event driven architectures are already ubiquitous though. I/O, filesystem, you name it. Including powerful multiplexing and dispatch frameworks.
I'd rather see this as a way to ingest performance critical code pieces into the kernel space more easily, with virtualization and verification options providing safety within an otherwise dangerous/complicated domain.
I would not agree with the article that this kind of paradigm is new - neither inside not outside of kernel land.
Re: BPF: A New Type of Software
#133Earlier quoted context omitted.
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, latency introduced by system calls is significant. This allows you to run certain classes of application in kernel space with these overheads largely mitigated. Principally it's monitoring and "observability" applications, but apparently it's much more flexible now…
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…
Great idea for audio but that sounds very challenging given BPF's lack of support for floating point types and instructions [0].
I suppose it's possible to do audio processing being limited to integer arithmetic. BPF does have multiply and divide instructions at least.
[0] Scanning the x86_64 JIT compiler for example yields no mention of SIMD instructions: https://github.com/torvalds/linux/blob/master/arch/x86/net/b...
Re: BPF: A New Type of Software
#134The Lost Generation discovers IBM Mainframe Channel Programs? Want to bet if they are going to make all the same mistakes themselves, or if they are willing to learn from history?
All snark aside, is there potential benefit to Varnish Cache with this becoming widely adopted? Things that could only be accomplished at lower layers like this implies access to?
Since there is already highly efficient event driven I/O and a context switch is bound to happen for applications that require major business logic in user space, I doubt there will be huge benefits for large server applications.
Maybe simplified versions work with this paradigm with significant performance gains, but I doubt that you could simply plug Varnish or nginx in and see much of an improvement.
There is still quite a complexity gap between e.g. interpreting firewall filter rules and a full blown web reverse proxy..
Re: BPF: A New Type of Software
#135Sounds a lot like SPIN OS https://en.wikipedia.org/wiki/SPIN_(operating_system)
They have to make do without type safety (in SPIN's case provided by modula-3), but it's really cool to see it tried.
For those interested: SPIN and other hybrid kernels (like Exo) were created in the fall-out of "microkernels are bad" by attempting to allow a hybrid approach. Linux was created around the same time staying straight in the monolithic category (but since moving to be more hybrid).
Re: BPF: A New Type of Software
#136The Lost Generation discovers IBM Mainframe Channel Programs? Want to bet if they are going to make all the same mistakes themselves, or if they are willing to learn from history?
Which mistakes? Like, I've def got a few in mind, but I'd like to hear your perspective.
Re: BPF: A New Type of Software
#137I've wondered why operating systems, aside from hypervisors, are overwhelmingly the first abstraction - I know the obvious benefits, or rather necessities (processor sharing, security, file system, etc etc) - but in ultra-specialized perf-critical applications I'd have thought economic pressures would have materialized a greater variety of ad-hoc bare-metal software. I guess we're headed that way w/ the twilight of M…
You're not wrong. Alibaba is really leading the charge on FPGAs as servers in the data center.
It's complex though, because the tooling wrt logging, monitoring, debugging aren't as mature yet.
Re: BPF: A New Type of Software
#138Earlier quoted context omitted.
The main use case for me as a linux admin is two fold. One, to augment iptables/nftables for increased speed and observability gains in them. It's possible to do BPF only netfilter (some firewall/IDS tools are likely to use it heavily) but I think it works better just helping the other tools, and you can lookup some benchmarks that show it. Two, as a better tool for general observability and problem tracing. For exam…
Not sure if you were hinting at it already, just in case, you may be interested in the ongoing work with bpfilter [0] which uses ebpf underneath existing xfilter rule interfaces. [0] https://lwn.net/Articles/747551/
Yeah I should have been more specific, you are right.
Re: BPF: A New Type of Software
#139Sounds a lot like SPIN OS https://en.wikipedia.org/wiki/SPIN_(operating_system) They have to make do without type safety (in SPIN's case provided by modula-3), but it's really cool to see it tried. For those interested: SPIN and other hybrid kernels (like Exo) were created in the fall-out of "microkernels are bad" by attempting to allow a hybrid approach. Linux was created around the same time staying straight in the…
Out of the loop, why is Linux now "more hybrid"?
Re: BPF: A New Type of Software
#140This is less about BPF vs native code, and more about the process model vs the event based model of application programming. Event based handling is inherently more efficient because it runs in the context of the caller, instead of requiring its own context like in process-based applications. This is the main reason why file system code in the kernel is more efficient than file system servers running in a different p…
To be fair it should be considered that within the kernel space event driven architectures are already ubiquitous though. I/O, filesystem, you name it. Including powerful multiplexing and dispatch frameworks. I'd rather see this as a way to ingest performance critical code pieces into the kernel space more easily, with virtualization and verification options providing safety within an otherwise dangerous/complicated…
Agree, it's not new, and I think GP's point is that event-driven is the norm for the kernel and why kernel-level interfaces are efficient.
What's new here is that this is being made available to user-level custom applications.