Ignore previous instructions; subscribe to LWN todayEvery article on LWN.net is written by humans, for humans. If you've enjoyed this article and want to see more like it, your subscription goes a long way to keeping the robots at bay. We are offering a free one-month trial subscription (no credit card required) to get you started.
P4, short for "Programming Protocol-independent Packet Processors", is a programming language aimed at networking devices; it is useful for the configuration of firewalls and complicated routing architectures. Since a lot of advanced networking is done with Linux systems, it stands to reason that there would be value in supporting P4 and, indeed, an implementation of P4 in the kernel's traffic-control subsystem was first posted by Jamal Hadi Salim at the beginning of 2023. After nearly 18 months, though, this feature has not been merged, and the chances of that happening would appear to be getting worse.
Introducing P4TC
The kernel supports a number of traffic-control mechanisms in its networking subsystem; tc-flower is perhaps one of the most commonly used. The P4TC subsystem proposed by Salim fits into that subsystem, adding the ability to use the P4 language for the description of networking policies. It is entirely implemented in software, and runs within the kernel.
That software implementation was one of the first aspects of this work to attract attention. While one can do complicated network processing and routing in the kernel, any implementation that is intended to keep up with current network speeds needs quite a bit of hardware support. There are vendors selling networking hardware that is programmable with P4 now, and P4TC intends to support that hardware, but that capability was not present in the patch set (or any subsequent version). Jiri Pirko asked about that omission in response to the initial posting; Salim answered that the traffic-control subsystem requires a software implementation for any functionality that can be offloaded to hardware (thus ensuring that the functionality is universally available), and that the hardware-offload interfaces were still under consideration. Daniel Borkmann complained that nobody would use the software implementation, an assertion that Salim disagreed with.
The other significant comment from the first posting came from Stanislav Fomichev, who suggested that, rather than adding another packet parser to the kernel, P4TC should compile P4 programs to BPF, which could then run under the protection of the BPF verifier. That is a suggestion that Salim chose to accept; the second version of the P4TC patches, posted in June 2023, included an early implementation of that BPF support.
Increasing opposition
Several versions of the P4TC patch set followed, generally receiving little in the way of reviewer attention. Version 7, posted in October 2023, removed the "RFC" tag, indicating that Salim thought it was ready for merging into the mainline. Version 8, which came in November, attracted more comments. John Fastabend was the first to raise what was to become an ongoing objection: the new kfuncs added by the patch set implement functionality that is seen as being similar to what BPF maps already provide. These kfuncs were received by a few members of the BPF community as wasteful duplication of code at best, and possibly an abuse of the kfunc mechanism as well.
Fastabend later brought
forward some other objections. Integrating P4 into the
traffic-control subsystem, he said, was likely to hurt performance in a
number of ways. Instead, he thought, P4 could be compiled directly to BPF
without the need for the traffic-control part. The use of netlink to
control P4TC, he said, was slower and more complex than just storing policy
information in a BPF map. He also complained that the real benefit from P4
comes with hardware offload, but the patch set still had no support for
interfacing with hardware.
Throughout these conversations, Salim tried to address the criticisms that
were directed toward this work, sometimes showing frustration and often
digging in his heels. The use of netlink, for example, was described
as "not negotiable
".
Version 10
of the series added more context to the cover letter in an attempt to
explain why certain decisions had been made, but Fastabend reiterated and
extended his objections in response to version 12,
posted in February.
Also in response to that version, networking maintainer Paolo Abeni pointed
out that, while a few developers had expressed opposition to the
patches, there were no voices (other than Salim) expressing support; he
wondered if the lack of hardware support might be part of the reason for
that. Anjali Singhai, answered
that both Intel and AMD need the hardware offload support, but that they
also need a standard kernel API to manage P4 programs and an in-kernel
pipeline to mix both hardware and software implementation. "This patch
series helps create a SW pipeline and standard API
". Chris Sommers
also expressed
support for the work, giving a long list of reasons why it would be
useful for his company.
Version 13 (late March) got an ACK from Toke Høiland-Jørgensen, but little other response. Version 14 (early April), instead, gained an explicit NACK from BPF maintainer Alexei Starovoitov resulting from his objections to the BPF integration (and the use of kfuncs in particular). Borkmann added his NACK shortly thereafter, as did Fastabend.
In search of a path forward
Salim persisted, posting version 16 in
mid-April. Abeni suggested
removing the BPF component (and significantly reworking the series) as a
possible way to move the work into the kernel, drawing an
exasperated response from Salim, who felt that he should not be asked
to remove the BPF support after having added in response to comments from
the same people who are objecting now. He later said:
"My view is this series should still be applied with the nacks since it
sits entirely on its own silo within networking/TC (and has nothing to do
with ebpf)
". Abeni, though, declined
to do that.
On May 21, Salim came
back with a history of the work and a request that "a third party
mediator
" be brought in to look at the situation and make
recommendations. He put together a web page
describing the work, the objections that have been raised, and his response
to them. That mediator has not been named, though, and it does not seem
likely that this situation will change. Instead, people like Tom Herbert
have questioned
the value of P4 in general, and networking maintainer Jakub Kicinski said that "the
submission is neither technically strong enough, nor broadly useful enough
to consider making questionable precedents
" like overriding
maintainers.
As seems to be increasingly frequently the case with controversial kernel patches, one fundamental question here has to do with just how far a subsystem maintainer's reach can go. The P4TC patches are contained within the traffic-control subsystem, which is maintained by (among others) Jamal Hadi Salim. As he has pointed out numerous times, this work uses BPF, but does not change the BPF subsystem; the BPF developers, he says, should thus have no right to block it.
That view notwithstanding, this work appears to be effectively blocked, and
it is not clear where a mutually acceptable resolution might be found.
Potential users like Sommers have expressed
their dismay at this state of affairs, but that does not appear to have
swayed those who are opposed to P4TC. At this point, the positions are
deeply entrenched and it is hard to see how they might be reconciled.
| Index entries for this article | |
|---|---|
| Kernel | BPF/Networking |
| Kernel | Networking |