bpf-next experiment

Alexei Starovoitov
2024-08-14T19:32:13Z

Hi All,

Couple years ago folks suggested that bpf-next should be
a separate pull request to increase subsystem visibility.
Back then we rejected the idea since many networking related
changes required bpf core changes. Things are different now.
bpf kfuncs can be added independently by various subsystems,
verifier additions are mainly driven by sched-ext,
so it's time to give it a shot. It's an experiment.
If things don't work out as expected we will go back to
the old model of feeding bpf trees through net/net-next trees.

So here is the plan:

1. bpf fixes go directly to Linus (skipping net tree) and
net/bpf trees are fast forwarded afterwards as usual.

2. Non-networking bpf commits land in bpf-next/master branch.
It will form bpf-next PR during the merge window.

3. Networking related commits (like XDP) land in bpf-next/net branch.
They will be PR-ed to net-next and ffwded from net-next
as we do today. All these patches will get to mainline
via net-next PR.

4. bpf-next/master and bpf-next/net branches are manually
merged into bpf-next/for-next branch.
This step achieves two objectives:
- bpf maintainers watch for conflicts between /master and /net
- Stephen Rothwell continues taking /for-next branch into linux-next
as usual

bpf CI will run tests against 4 trees (instead of 2):
bpf, bpf-next/master, bpf-next/net, bpf-next/for-next.
This is wip. Watch for more "Checks" in patchwork.

By the merge window in September we will reassess
the situation and if it's still worth doing we will
proceed with PR formed from bpf-next/master.
If not, we will PR bpf-next/master into net-next and
call it a failed experiment.

We feel that there are more positives to this process
than headaches, so fingers crossed.