This goal of this tiny write-up is to summarize the stuff I've learned about eBPF, as well as a couple of tangential topics that I have found useful. I do not guarantee the information here to be 100% correct - if you find an error, please ping me on twitter via @ayourtch and I will be happy to amend it as well as learn in the process!
I found [1] to be invaluable reading on the subject, as well as the outgoing references from it.
There are four types of eBPF programs:
This type of program attaches the kprobe to a kernel function. A couple of very good reads on the subject are in [3], [4]. Go through them first, as well as through the [1].
There is no simple way to alter the return value of the kernel function call - so this is a great way to capture the running information but is not a great generic way to modify the behavior of the kernel.
With this post, you can find ebpf_kprobe.py, which experiments with capturing the send events as well as received packet events (Just IPv6)
Attaching the BPF program to a socket causes the specified filter to be applied to that socket
The programs of this type operate on skb only, and allow the alteration of the behavior (e.g. encap/decap)
From the commit in [6]:
This is bascially analogous to 96be4325f443 ("ebpf: add sched_cls_type and map it to sk_filter's verifier ops").
BPF_PROG_TYPE_SCHED_CLS and BPF_PROG_TYPE_SCHED_ACT need to be separate since both will have a different set of functionality in future (classifier vs action), thus we won't run into ABI troubles when the point in time comes to diverge functionality from the classifier.
The future plan for act_bpf would be that it will be able to write into skb->data and alter selected fields mirrored in struct __sk_buff.
For an initial support, it's sufficient to map it to sk_filter_ops.