Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

BPF: A New Type of Software

brendangregg.com

Post reply on HN
Print view View original

21–30 of 192 posts

Re: BPF: A New Type of Software

#21

Post by megous »

maxdamantus wrote: post #13
Iv wrote: post #6

So from my understanding, that's a kind of "secure" (I'd like to know more about the security model tbh) module that runs with kernel privilege with no scheduling (so it runs until completion). These are supposed to be short and I am assuming, can't call libs and can't allocate memory (outside a predefined stack I would guess?) Aren't they very similar to interrupts? What is the difference there? The kernel API?

I think it's more to do with avoiding overheads typically associated with system calls (presumably involving some interrupt and disabling/enabling/changing paging behaviour). Here's an example of a syscall-heavy command on my system: $ time dd if=/dev/zero bs=1 count=10M of=/dev/null 10485760+0 records in 10485760+0 records out 10485760 bytes (10 MB, 10 MiB) copied, 7.09089 s, 1.5 MB/s real 0m7.092s user 0m2.123s sys…

Re-try with mitigations=off

Re: BPF: A New Type of Software

#22

Post by kbumsik »

yetihehe wrote: post #4

Looks nice, microservices going into super-micro territory, where they are just simple small code snippets. Possible problems - many people will learn the hard way that logging or printing every packet which comes through your interfaces for further analysis will bring down your system. From the start there should be some simple way to rate-limit those bpf programs, like "if this exceeds some limits or bogs down syst…

> "if this exceeds some limits or bogs down system for more than X milliseconds, disable and give error".

AFAIK indefinite loops in a BPF are not allowed: The kernel eBPF verifier will reject to load such programs. So the execution time of BPF programs will not be variable time and will be predictive.

I'm not sure if users need to care about the cases of long execution times when no loops are allowed.

Re: BPF: A New Type of Software

#24

Post by ignoramous »

rusk wrote: post #19
jokoon wrote: post #16

I have a hard time understanding what you would use it for. I could understand a use-case, but I fail to understand why it would be that much useful. I have a sense it allows much better performance for horizontal scaling, but I'm not sure...

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…

> 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

Re: BPF: A New Type of Software

#26

Post by joosters »

maxdamantus wrote: post #13
Iv wrote: post #6

So from my understanding, that's a kind of "secure" (I'd like to know more about the security model tbh) module that runs with kernel privilege with no scheduling (so it runs until completion). These are supposed to be short and I am assuming, can't call libs and can't allocate memory (outside a predefined stack I would guess?) Aren't they very similar to interrupts? What is the difference there? The kernel API?

I think it's more to do with avoiding overheads typically associated with system calls (presumably involving some interrupt and disabling/enabling/changing paging behaviour). Here's an example of a syscall-heavy command on my system: $ time dd if=/dev/zero bs=1 count=10M of=/dev/null 10485760+0 records in 10485760+0 records out 10485760 bytes (10 MB, 10 MiB) copied, 7.09089 s, 1.5 MB/s real 0m7.092s user 0m2.123s sys…

How much of that time is really spent in the system call interface?

You've got 4.968s of system time there (i.e. broadly the time spent in kernel code) and 2.123s of user time. Given that the user-space program is effectively a tight loop around read() and write() calls, we can assume that almost all of those 2 seconds are spent going through the syscall plumbing.

Now, there's going to also be some of the kernel-side time spent in the syscall plumbing too, but there's also a lot of I/O, buffer and filesystem layer code executing there. All of which will be in use with a BPF program too. So it's unclear how much of the effective time can be shaved off.

Re: BPF: A New Type of Software

#27

Post by rusk »

z3t4 wrote: post #20
rusk wrote: post #19

Earlier 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…

Wouldn't virtualization kill the perf benefit, or is this supposed to run "on the metal"?

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.

Re: BPF: A New Type of Software

#28

Post by arminiusreturns »

jokoon wrote: post #16

I have a hard time understanding what you would use it for. I could understand a use-case, but I fail to understand why it would be that much useful. I have a sense it allows much better performance for horizontal scaling, but I'm not sure...

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 example, I recently listened to a Usenix (LISA19) talk by Brendan Gregg (author of this blog) about linux systems perf at Netflix where he talks about how much strace can impact performance and he posits the future replacement for it will be 'perf trace' which uses ring buffer and BPF. [1]

1[] https://youtu.be/fhBHvsi0Ql0?t=1300

Re: BPF: A New Type of Software

#30

Post by andbberger »

kbumsik wrote: post #22
yetihehe wrote: post #4

Looks nice, microservices going into super-micro territory, where they are just simple small code snippets. Possible problems - many people will learn the hard way that logging or printing every packet which comes through your interfaces for further analysis will bring down your system. From the start there should be some simple way to rate-limit those bpf programs, like "if this exceeds some limits or bogs down syst…

> "if this exceeds some limits or bogs down system for more than X milliseconds, disable and give error". AFAIK indefinite loops in a BPF are not allowed: The kernel eBPF verifier will reject to load such programs. So the execution time of BPF programs will not be variable time and will be predictive. I'm not sure if users need to care about the cases of long execution times when no loops are allowed.

How is that possible?? If true, that would imply BPF programs are not Turing complete.
Post reply on HN