Summary

  • Jamal Hadi Salim is publicly identified in 2026 as Linux Traffic Control’s maintainer, but tc remains a collective system shaped by decades of contributors and users.
  • His work connects Netlink, the IETF’s ForCES standards and P4TC, three different attempts to expose forwarding behaviour through durable, programmable interfaces.
  • P4TC’s production test is operational rather than linguistic: provisioning, permissions, counters, rollback and replay must work across kernels, controllers, drivers and hardware.
  • Common tc syntax can still conceal different software, fallback and offload behaviour, leaving capability discovery and failure reporting as the project’s decisive risks.

The old tc interface now carries modern policy

In 2026, P4 community material identified Jamal Hadi Salim as the maintainer of Linux Traffic Control and the lead of P4TC. The titles place him at a boundary few users see. A terse tc command can set a bandwidth ceiling, attach a classifier, redirect traffic, count flows or ask a network interface to offload a rule. The command looks old; the contract beneath it is still being extended.

Traffic Control began with queueing and scheduling. It now acts as a general packet-control surface built from queueing disciplines, classes, filters and actions. Cloud hosts and network appliances can use it to shape egress, inspect ingress, mirror traffic or enforce policy. Netlink carries instructions between user space and the kernel, while drivers decide whether some work can move into hardware.

Salim’s career runs through each layer. Public records associate him with Mojatatu Networks, the Netdev community, RFC 3549 on Netlink, the IETF’s Forwarding and Control Element Separation work and the current P4TC effort. That history makes him more than the subject of a maintainer biography. It provides a way to examine a difficult infrastructure question: how can Linux accept a more programmable packet pipeline without invalidating the scripts, drivers and appliances already built around tc?

Adding a parser or compiling a P4 program does not answer that question. Linux networking is a contract among kernel code, user-space tools, hardware drivers, applications and operators. A new Netlink attribute can become a lasting user-space application binary interface. A rule that behaves correctly in software may be only partly offloaded by a network interface card. A pipeline that loads successfully may still be unsafe to change during live traffic or impossible to replay after a restart.

Salim has spent much of his career at this contract boundary. Early tc work helped establish reusable packet actions and scheduling structures. Netlink supplied a structured control channel. ForCES attempted to standardise the relationship between separate control and forwarding elements. P4TC now seeks to represent a P4-described pipeline inside Linux Traffic Control rather than through a separate software switch or a vendor-specific software development kit.

These projects belong to different technical eras, and none is a simple earlier version of the next. ForCES is not P4TC under another name. Netlink is not a universal device-control protocol. Traffic Control is not one algorithm. The continuity lies in the discipline each requires: define a programmable model, expose it through an interface other software can rely on, and keep the interface supportable after the original implementation team moves on.

That final condition separates infrastructure from demonstration. A research prototype can change its schema and be rebuilt. A Linux interface used by routers, clouds and appliances cannot be revised casually. P4TC’s importance will depend less on whether one demonstration processes packets than on whether compilers, controllers, drivers and maintainers can agree on a contract operators can inspect, upgrade and roll back.

Queueing became a general packet-control framework

The Linux packet path contains several places where policy can be applied. At egress, packets wait in a queue before transmission. At ingress, they can be classified before entering later networking layers. Traffic Control organises these functions through objects with distinct responsibilities.

A queueing discipline, or qdisc, determines how packets are queued and scheduled. Some qdiscs are simple; others create classes with their own rates and priorities. Filters match traffic according to headers, metadata or other keys. Actions apply operations after a match. The architecture allows a policy to be assembled rather than embedded as one monolithic function.

This composition created long-term value. An operator could replace one scheduler without rewriting every classifier. A new action could be reused by several filters. Driver developers could offload particular matches and actions to hardware. Research systems could test new queueing and classification ideas inside a common framework. The price was complexity. A packet may encounter several hooks and objects, each with its own counters, order and fallback path.

Salim’s documented contribution includes the action architecture that helped make tc broader than scheduling. Actions such as redirect and mirror are now ordinary building blocks in host networking. They allow traffic to be sent to another interface, copied for observation or subjected to a sequence of operations. In cloud and appliance environments, those primitives can participate in service chaining and policy enforcement.

Composability does not guarantee comprehensibility. An operator debugging a failed policy needs to know which classifier matched, whether the action executed in software or hardware, which counter belongs to the actual path and whether a driver silently declined part of the request. If a rule is accepted but not fully offloaded, performance can change while semantics appear intact. If an unsupported combination is rejected, automation must interpret the error correctly.

The framework’s age adds another constraint. Existing qdiscs and classifiers have users whose configurations may never appear in public repositories. Appliances can ship old scripts. Distributions backport features. Operators depend on output formats and error behaviour. Kernel developers therefore treat user-space compatibility as infrastructure, not as an inconvenience to be cleaned up during a redesign.

Salim’s maintainer role is important here. A maintainer does not own every line or decide alone what enters Linux. Changes move through public mailing lists, subsystem review and higher-level networking trees. Yet maintainers carry the tacit history needed to recognise when a new abstraction duplicates an old one, breaks an established contract or creates an interface that cannot be supported safely.

Traffic Control remains relevant to current programmability work because it already supplies the surrounding operational machinery. It already has hooks, object lifecycles, permissions, statistics, Netlink encoding and hardware-offload paths. Building P4 functionality on that base can reuse an installed control surface. It also inherits every ambiguity and compatibility obligation accumulated over decades.

Netlink turned implementation details into promises to user space

Netlink is the structured messaging mechanism through which many Linux networking tools communicate with the kernel. The ip and tc utilities use it to create and inspect objects. Controllers and management systems can construct the same messages directly. Salim’s RFC 3549, published in 2003, documented Netlink in the context of IP services and helped make the interface legible beyond the kernel source.

The essential idea is straightforward. User space sends messages containing a command and typed attributes. The kernel validates them, changes state and returns acknowledgements or data. The format is extensible: new attributes can be added without replacing the whole protocol. That flexibility helped Linux networking grow from basic routes and addresses into a large family of objects.

Extensibility, however, creates governance work. Attribute identifiers must not be reused casually. Nested structures need consistent rules. Error messages must tell applications which field failed. Dump operations must behave predictably while state changes. A controller needs to know whether an older kernel ignores, rejects or partially understands a new attribute.

An internal data structure can be changed by recompiling the kernel. A Netlink attribute becomes a long-lived user-space commitment once tools and automation depend on it. This is the hidden constitutional role of the interface. It decides not only how a feature is configured today but how future software can discover capabilities and coexist with old deployments.

P4TC intensifies this problem because a programmable pipeline contains many object types: parsers, tables, actions, externs, metadata and runtime entries. Encoding them as Netlink resources requires more than assigning numbers. The design must express hierarchy, identity, references, permissions and versioning. It must distinguish creation of a pipeline model from modification of a table entry inside an already instantiated pipeline.

Salim’s 2026 P4 Developer Day presentation described a resource-oriented runtime model carried over Netlink, with compiler-generated information and annotations that help applications discover object paths. The use of concepts familiar from REST does not turn the interface into HTTP, and it does not make it equivalent to P4Runtime. The work is a Linux-specific control model shaped by kernel APIs.

The risk is that convenience during development becomes permanent complexity for operators. A path name or JSON description generated by a compiler may be easy for one controller to consume. It still needs stable semantics across compiler versions and kernels. If an object moves or an annotation changes, the system needs a migration story. If a kernel rejects an entry, the controller must know whether the failure reflects syntax, permission, unsupported hardware or insufficient resources.

Netlink therefore anchors the main tension in Salim’s work. It makes networking programmable through a common channel, but every successful use turns design choices into obligations. P4TC will be credible as infrastructure only when those obligations are treated as part of the feature rather than as documentation to be completed after the packet path works.

ForCES showed that a complete standard still needs a deployment coalition

Before the current P4 ecosystem, the IETF’s Forwarding and Control Element Separation work addressed a similar desire: allow a control element to configure and query forwarding elements through a standard model and protocol. Salim chaired the working group and co-authored central parts of the RFC family.

The ForCES model represented forwarding behaviour as logical functional blocks. A forwarding element could expose capabilities and state, while a control element used a protocol to configure the pipeline. RFC 5810 defined the protocol. RFC 5812 provided an extensive forwarding-element model. Additional documents covered transport mapping, interoperability, programmability extensions and communication among forwarding elements.

The work was substantial by any standards measure. It produced detailed specifications, multiple implementations and an interoperability report. It also did not become the dominant architecture for programmable networking. That outcome is analytically useful because it shows what standards cannot guarantee.

A protocol can be rigorous and still lack a sufficiently large deployment coalition. Equipment vendors may prefer their existing control systems. Operators may see migration risk without a compelling economic benefit. Competing architectures can attract more software, hardware and developer attention. The standard may cover a broad problem while the market adopts narrower solutions that are easier to integrate.

ForCES also emerged during a period when software-defined networking was being defined in several ways. OpenFlow later concentrated attention on match-action control of switch tables. Network function virtualisation moved functions into software. P4 focused on describing packet-processing behaviour for programmable targets. These approaches overlapped with ForCES in the broad separation of control and forwarding, but their models, communities and implementation paths differed.

Describing P4TC as the completion of ForCES would be misleading. There may be intellectual continuity in model-driven forwarding, and Salim’s experience spans both. Yet P4TC works inside Linux Traffic Control, uses P4 descriptions and relies on kernel review and Netlink. ForCES defined a protocol between distinct control and forwarding elements. The technical objects and adoption environments are not the same.

The strategic lesson is more general. Interoperability tests prove that implementations can communicate under defined conditions. They do not prove that vendors will ship the feature broadly, that operators will train staff or that the support ecosystem will persist. A standard becomes infrastructure only when organisations align procurement, maintenance and migration around it.

Salim’s current P4TC work appears informed by that history. It seeks to attach programmability to a platform operators already use rather than requiring an entirely separate forwarding architecture. This can lower adoption barriers. It can also constrain the design because Linux must preserve existing behaviour. The installed base is both advantage and burden.

P4TC brings P4 into Linux rather than around it

P4 is a language for describing how programmable network targets parse packets, apply tables and actions, maintain state and emit results. It is commonly associated with switch ASICs and software switches, but the language itself is target-oriented. A compiler maps the program onto an architecture and implementation.

P4TC’s proposition is that Linux Traffic Control can serve as one such target. A P4-described pipeline can be represented through kernel objects and executed in the Linux packet path. This gives developers a way to express packet processing in P4 without moving traffic into a separate user-space switch or requiring specialised hardware.

The attraction is practical. Linux already runs on servers, appliances and edge systems. It already has security and lifecycle mechanisms, network namespaces, traffic hooks and a mature operator community. If P4TC fits upstream practice, an application could use P4 concepts while remaining within ordinary kernel deployment and packaging.

The phrase “run P4 in Linux” conceals several layers. The compiler must understand the P4 program and produce a form the kernel can provision. The kernel must instantiate parsers, tables, actions and metadata while enforcing memory and permission limits. A runtime controller must create and update entries. Tools must inspect state and counters. Hardware drivers may offload some functions. Tests must compare the intended P4 behaviour with what actually runs.

P4TC separates provisioning from runtime control. Provisioning establishes the pipeline manifestation: the kinds of objects that exist and how they relate. Runtime operations manipulate instances, such as table entries. This is a necessary operational distinction. Changing a table entry can be routine. Replacing the pipeline model may alter packet interpretation and require a coordinated transition.

The separation also creates rollback questions. If a new pipeline fails validation or performance targets, can the old one remain active? What happens to runtime entries during an update? Are counters preserved? Can two versions coexist? A laboratory demo can restart the environment. A production host may be carrying traffic for thousands of workloads.

By August 2026, public records described active architecture, APIs, papers and patch work. Those records do not justify calling P4TC a universally available Linux feature. Upstream status and capabilities need to be checked by kernel release and patch series. Compiler support must match the kernel implementation. Operator guidance should date every claim.

This caution is not a criticism of the project. Active kernel work changes. The correct maturity label helps developers decide whether they are experimenting, building a controlled appliance or relying on a distribution-supported feature. Overstating availability would undermine the compatibility discipline P4TC is trying to achieve.

Loading a pipeline is an operational change, not a compile step

A programmable pipeline is often discussed as source code: write a P4 program, compile it and run it. Production systems need a more detailed lifecycle. The code must be approved, its resource requirements understood, its target verified and its deployment coordinated with the control plane.

P4TC’s provisioning interface is intended to describe the pipeline objects the kernel will create. Parsers define how headers are recognised. Tables define match keys and possible actions. Externs represent target-specific capabilities. Metadata connects stages. The provisioned result is the schema within which runtime policy operates.

This step is analogous to installing a new network function rather than changing a setting. A parser error can misinterpret traffic. A table can consume more memory than expected. An action can interact poorly with existing hooks. An extern may be unavailable on one kernel or device. The system needs validation before traffic reaches the new path.

Versioning becomes essential because the compiler and kernel share responsibility for the schema. If the compiler emits a construct the kernel interprets differently, the program may load but behave incorrectly. A reliable process records compiler version, kernel version, pipeline identifier and capability set. It should reject ambiguous combinations rather than relying on best effort.

Permissions also matter. Loading a new packet-processing pipeline is a powerful operation. It can redirect traffic, bypass policy or expose metadata. Linux namespaces and capabilities may constrain who can provision objects, but the security model must be clear for containers and multi-tenant hosts. The runtime interface cannot be treated as an ordinary application API merely because it is programmatic.

Operational observability must begin at provisioning. Engineers need to inspect which objects were created, which features were unsupported and how resources were allocated. A successful acknowledgement should not imply that performance goals are met. A pipeline can be valid and still overload a CPU or introduce latency.

The need for staged rollout is obvious. A new pipeline should be tested in emulation or a lab, loaded on a canary host, compared against expected packet traces and monitored under real load. Rollback needs to be rehearsed, not assumed. These practices belong to the deployment architecture rather than to an external operations manual.

Salim’s insistence on using Linux’s established control framework gives the project a place to implement these controls. It also means P4TC cannot avoid the kernel community’s demands for clear semantics and maintainable interfaces. Provisioning is where a language feature becomes a durable operator commitment.

Runtime control must expose state, capability and failure

Once a pipeline exists, controllers need to populate tables, read counters and update policy. The P4TC runtime API addresses this phase. Project presentations describe resource paths, annotations and compiler-generated JSON that allow applications to discover and manipulate objects over Netlink.

The design aims to reduce tight coupling between a controller and one specific P4 program. If the controller can inspect the object model, it can construct operations dynamically. This is attractive for orchestration systems managing several pipelines or versions.

Discovery does not create portability by itself. Two P4 programs may use similar object names with different meanings. Compilers may emit different annotations. Targets can support different externs and resource limits. Error handling may vary depending on whether execution occurs in software or is offloaded. The runtime needs conventions strong enough that automation does not confuse syntactic similarity with semantic equivalence.

The relationship to P4Runtime also needs precision. P4Runtime is a standard control-plane API for P4-programmed devices. P4TC’s runtime model is carried through Linux Netlink and reflects kernel objects and permissions. The projects can share concepts without being substitutes in every environment. An operator choosing between them is also choosing a target and lifecycle model.

Runtime updates create consistency problems. A controller may change several table entries that should take effect together. Packets can arrive between updates. A failed operation can leave partial state. If the pipeline is replicated across hosts, versions can diverge. Transactions, generation identifiers and clear failure semantics become more important as the policy grows.

Counters need equal scrutiny. A controller may read a software counter while traffic is actually offloaded. Hardware may aggregate values differently or update at another cadence. A fallback to software can create a sudden performance change while preserving the rule’s apparent state. Observability must identify where execution occurred.

These issues are familiar in network automation, but P4TC concentrates them in a programmable dataplane. The more expressive the pipeline, the more ways its control state can become inconsistent with operator intent. Less programmability would not solve the problem. The runtime contract must make state, capability and failure explicit.

By August 2026, that contract remained active work. Progress is better measured through stable object semantics, tests across kernels and compilers, documented rollback and independent implementations that agree on behaviour than through a broad claim of P4 compatibility.

Hardware offload is where common syntax stops guaranteeing common behaviour

Linux Traffic Control already supports hardware offload through driver interfaces. A filter or action can be translated into NIC or switch hardware, allowing packets to be processed without consuming the host CPU. This is important for performance and power. It also exposes a structural limit of abstraction.

Hardware has finite tables, specific match fields, action combinations and ordering constraints. One device may support a redirect followed by modification; another may not. A driver may offload part of a rule and leave the rest in software. Some systems reject unsupported combinations; others use fallback. The same tc command can therefore produce different performance and, in poorly handled cases, different behaviour.

P4TC does not remove this variation. P4 programs are compiled for targets with particular architectures. A kernel software target can implement constructs that a NIC cannot offload. A vendor may expose proprietary externs. An operator needs a capability model and tests of the deployed target as well as the source program.

The promise of portability is most easily overstated at the offload boundary. A common language can make intent easier to express and tooling easier to share. It cannot create hardware resources that do not exist. It cannot ensure that two devices handle counters, ageing, errors or atomic updates identically. Portability is a spectrum measured by the subset of behaviour preserved across targets.

Salim’s work sits at an unusually difficult junction because tc spans software and hardware paths already. The maintainer must consider the semantic contract, while driver authors implement offload and vendors decide which features receive engineering resources. P4TC adds a richer language and schema to that relationship.

Operators should demand explicit execution state. A rule should reveal whether it is in software, hardware or a hybrid path. Unsupported objects should fail clearly. Counter provenance should be visible. Performance tests should include fallback and failure, not only the ideal offloaded case.

Hardware lifecycle further complicates support. A kernel API may remain stable for years while a NIC generation is replaced. Drivers can be backported or vendor-modified. Firmware updates can change behaviour. The open interface reduces dependence on one CLI, but it does not remove dependence on the vendor’s implementation and support window.

A perfectly uniform dataplane is unlikely. P4 descriptions, Linux objects and hardware capabilities will instead have to negotiate a workable subset. The quality of that negotiation will determine whether P4TC becomes dependable infrastructure or remains mainly an experimentation surface.

Counters and replay decide whether the pipeline is operable

A packet-processing system is not ready for production merely because it accepts a program and forwards a test packet correctly. Operators need to know what was installed, where it is running, how many packets matched, why an update failed and whether the state they read is the state the dataplane is actually using. These questions are mundane compared with language design, but they determine whether a programmable pipeline can be supported at three in the morning.

Traffic Control already contains several forms of operational evidence. Queueing disciplines expose packet, byte, drop and over-limit counters. Filters and actions can report hits and outcomes. Netlink dumps let user space reconstruct configured objects. Extended acknowledgements can carry more useful error messages than a bare failure code. Hardware offload paths may add their own statistics or indicate that a rule was accepted in software rather than in the device. The quality and consistency of this evidence vary by object and driver, which is precisely why P4TC cannot treat observability as an afterthought.

A P4 pipeline introduces a richer state model. A table entry may refer to an action profile, a counter, a meter, a register or metadata defined by the program. A compiler may assign identifiers and encode types. A controller may install state through a runtime API while another process reads counters or changes a default action. If those objects are visible only through the controller that created them, the common Linux interface becomes less useful. If the kernel exposes them without preserving their P4 meaning, operators receive raw objects that are difficult to relate to the source program.

The 2026 P4TC material attempts to bridge that gap through resource-oriented paths and compiler-generated descriptions. The point is not cosmetic naming. A controller needs a stable way to address an object and understand its type. A diagnostic tool needs to show the same object in terms an engineer can connect to the P4 source. When the pipeline changes, the system needs a rule for whether old entries remain valid, are translated or must be rejected. A mismatch should fail loudly enough that automation does not mistake partial state for success.

Error reporting becomes especially important when resources are finite. A software table may accept more entries than a NIC can offload. An action may be valid in the language but unsupported by a driver. A meter may require a granularity the hardware cannot represent. A controller should be able to distinguish malformed input, missing capability, exhausted resources and transient failure. Treating all four as EINVAL or a generic rejected update would push expensive interpretation into every operator’s automation.

Counters have similar ambiguity. A packet counter may count in the hardware, in the software fallback path or in both. It may reset when a rule is replaced, wrap at a device-specific width or lag behind because it is polled. A controller that reads a value without knowing its execution location can draw the wrong conclusion about traffic. For billing, security or capacity planning, that is not a small discrepancy. It changes what the measurement means.

The problem is not unique to P4TC. Linux networking has long struggled to present uniform statistics over devices with different hardware. What changes is the scale of the semantic surface. A P4 program can define objects that did not exist when the driver was written. The system therefore needs capability discovery and failure semantics that are precise enough for automation but stable enough for the kernel ABI.

Replay is another practical test. After a host reboots, a driver resets or a controller fails over, the desired pipeline and entries must be reconstructed. The kernel can preserve some state across a process restart, but not across every failure. Controllers need an authoritative desired-state store and a way to compare it with the dataplane. A dump that omits dependencies or returns objects in an unstable order complicates recovery. A pipeline whose compiler identifiers change between builds can make replay unsafe even when the P4 source appears unchanged.

Good operational design would make these cases testable. Selftests could create a pipeline, populate related resources, force an error, dump state, restart a controller and confirm that counters and entries retain defined meaning. Hardware qualification could repeat the sequence with offload enabled and verify which steps remain in the device. Documentation could state where atomicity ends rather than leaving users to discover it through outages.

Salim’s long work on Netlink and tc gives P4TC an advantage here. The project begins inside an ecosystem that already treats introspection, dumps and error codes as part of the API. It also inherits the ecosystem’s inconsistencies. The decisive engineering work is not simply adding more object types. It is making their lifecycle legible to operators who did not write the compiler or driver.

Linux already has several dataplanes, and P4TC fits one of them

P4TC enters a Linux landscape that is already crowded with ways to process packets. eBPF programs can attach at several points in the networking stack. XDP runs early in the receive path and is used for filtering, load balancing and denial-of-service defence. DPDK gives user-space applications direct control of cores, memory and NIC queues. Open vSwitch provides a programmable virtual-switch model. FD.io’s VPP organises packet functions as a vector-processing graph. A vendor SDK may expose the deepest access to a particular ASIC.

These systems overlap, but they are not interchangeable. Their differences begin with where they run and what they are prepared to own. XDP is attractive when the work should happen before the full kernel stack. eBPF has a verifier, maps, helpers and a large attachment ecosystem. DPDK is attractive when an application can dedicate resources and take responsibility for the dataplane. Open vSwitch and VPP offer broader switching or routing frameworks. Traffic Control sits at ingress and egress boundaries already used for classification, policing, shaping and actions tied to Linux devices.

The comparison matters because a claim that P4TC “brings P4 to Linux” can be heard as a promise to replace these alternatives. That is not supported by the architecture. P4TC gives P4-defined packet processing a tc representation and Netlink control surface. It does not automatically provide XDP’s earliest hook, DPDK’s user-space execution model, VPP’s vector graph or a switch ASIC’s full pipeline.

P4 itself brings a different strength: a language designed to describe parsers, match-action tables, metadata and deparsing. That structure can make a dataplane easier to reason about than a set of unrelated hook programs. It can allow a controller to work with named tables and actions rather than loader-specific bytecode. For teams already using P4 in switches or SmartNICs, a Linux target can reduce the conceptual distance between hardware and host processing.

The cost is another toolchain and semantic layer. eBPF developers use Clang, libbpf, BTF and kernel helpers. P4TC developers need a P4 compiler that understands the kernel target and emits the information required by the provisioning API. The two ecosystems have different safety models. The eBPF verifier reasons about bytecode and kernel interactions. A P4 pipeline is checked through language and compiler rules, then translated into tc objects and kernel execution. Neither model removes the need to validate generated behaviour.

Performance comparisons also need discipline. XDP can avoid work by acting before socket allocation. DPDK can dedicate an entire core to polling. tc can reuse the kernel’s device and scheduling context. Results depend on packet size, action complexity, CPU, NIC, cache behaviour and whether hardware offload is available. A benchmark that shows one system winning a narrow test does not settle which operating model is cheaper to maintain.

Operators often combine the mechanisms. XDP may drop obvious attack traffic, tc may enforce policy and shape egress, and a DPDK application may handle a specialised service. eBPF classifiers have long been used with tc. Hardware offload may translate a subset of tc flower rules while software handles the rest. The real question is therefore not which framework wins, but whether their boundaries are explicit enough to avoid duplicated or contradictory policy.

A P4TC pipeline could, for example, classify traffic that an XDP program already modified. Metadata may not pass between hooks in the form an application expects. Two control systems could update overlapping rules. Counters may be split across layers. Troubleshooting then requires a packet biography across several execution environments. Programmability has multiplied the number of places where intent can live.

Common lifecycle practice matters more than ideological purity. A production team needs ownership rules: which layer handles admission, which handles shaping, which may redirect traffic, and which system is authoritative for each counter. Changes need coordinated rollout. Emergency rollback needs to work even when one controller is unavailable. The open-source ecosystem provides choices; it does not make those choices self-coordinating.

P4TC’s opportunity lies in jobs that match tc’s established role and benefit from P4’s structured model. It can make complex classification and actions more portable across Linux hosts and potentially offload targets. It can provide a common language for a class of pipelines that would otherwise be encoded in vendor rules or bespoke tc commands. It does not need to become the one dataplane to be consequential.

Salim’s broader record supports that more modest reading. ForCES was an attempt to create explicit control and forwarding models, not to abolish every device architecture. Traffic Control grew by composing mechanisms rather than replacing the stack. P4TC can succeed in the same way: by giving Linux a durable new vocabulary while respecting that different packet paths exist for different operational bargains.

A maintainer’s power lies in refusing contracts Linux cannot keep

Salim’s current identification as the Linux Traffic Control maintainer is easy to misread as ownership. Linux maintainership is closer to delegated custody. A maintainer can review, request changes, reject an interface and assemble patches for the next integration step. The authority is substantial because an accepted Netlink attribute or action can become a contract used for years. It remains constrained by peer review, higher-level networking maintainers, release practice and the willingness of contributors to maintain what they add.

Attribution matters here because authored lines are only one measure of influence. Salim’s record includes standards, subsystem architecture, review and community work. A maintainer may shape a feature by insisting that it use a general object model, expose statistics or preserve compatibility, even when another engineer writes most of the code. Conversely, a sign-off does not mean the maintainer invented every mechanism in the patch.

The traffic-control subsystem makes this form of authority unusually durable. Operators embed tc commands in boot scripts, orchestration tools, container platforms and vendor appliances. A seemingly obscure syntax or default can become production dependency. Removing it later can break systems that maintainers cannot see. Review therefore weighs not only whether a patch works, but whether the interface can be supported after the original contributor changes employer or interest.

P4TC raises the stakes because it invites a broader toolchain to rely on the kernel. Compiler-generated object descriptions, controller APIs and hardware drivers may all encode assumptions about the common contract. A decision made for an early prototype can become difficult to revise once those layers ship. The maintainer’s most valuable intervention may be to slow the feature until failure semantics and versioning are clear.

This caution can look conservative to researchers and vendors racing to demonstrate capability. From the operator’s perspective, it is a form of innovation insurance. Linux succeeds partly because new mechanisms enter a system with an expectation of long-term compatibility. The cost is that upstreaming can be slower than maintaining a private fork.

Private forks offer speed and concentrate risk. A vendor can tailor P4TC to its compiler or device and deliver a product before the upstream design settles. Customers then depend on that kernel, toolchain and support contract. Upstream review is the route by which the useful part can become a shared interface, but only if the vendor is willing to adapt its implementation to community requirements.

Salim’s career across Netlink, ForCES and P4TC makes his significance less about one invention than about this translation. Standards define a model; code exposes a Linux interface; maintainers decide whether the model fits the operating system’s obligations. The authority is real precisely because it is exercised through constraints rather than personal ownership.

Paid engineering decides which parts of the commons are maintained

Open-source infrastructure is often described as if code appeared from a neutral community outside ordinary economics. Linux networking does not work that way. Contributors are employed by cloud companies, hardware vendors, distributions, consultancies and operators. Conferences require sponsors. Test systems need machines and staff. Maintainers need time to read patch series whose commercial value may accrue to organisations that never appear in the commit log.

Salim’s work through Mojatatu Networks sits inside this reality. Public records support his role as an engineer and community leader associated with the company, but they do not provide a project-by-project budget for tc or P4TC. The sensible conclusion is not that funding is absent. It is that the labour model is distributed and only partly visible.

Commercial support can be healthy for an upstream project. A consultancy can help an operator deploy an unfamiliar feature, turn production failures into patches and fund engineers who understand both the customer problem and the kernel process. The work becomes dangerous when one sponsor’s private roadmap is mistaken for community consensus or when essential maintenance depends on a contract that can disappear without notice.

P4TC has an additional economic challenge because it crosses organisational boundaries. Compiler developers, kernel maintainers, NIC vendors and controller teams may be funded by different employers. A feature can be valuable only when all of them complete compatible work. No single organisation necessarily captures enough revenue to pay for the unglamorous integration between layers.

This coordination problem helps explain why mature standards can remain underused. ForCES defined interfaces, but vendors and operators needed a commercial reason to build and support both sides. P4TC can reuse Linux and P4 ecosystems, yet it still needs distributions to package the tools, hardware vendors to implement offload, controller developers to support the API and operators to publish requirements. A working demonstration is cheaper than a supportable supply chain.

Governance can reduce the risk by making dependencies visible. Public roadmaps should distinguish funded work from hoped-for contributions. Maintainer files and review records should show where expertise is concentrated. Test infrastructure should not depend on one inaccessible lab. Documentation should make software execution useful even when hardware support is incomplete, so the project is not held hostage by a particular device.

Compatibility also raises a question of who pays for it. A vendor benefits when Linux supports its hardware, but the community carries the ABI indefinitely. Maintainers therefore ask whether an interface is general enough to justify that burden. A controller vendor may prefer a feature that maps neatly to its product, while the kernel needs semantics that other controllers can use. These disagreements are not obstruction. They are the mechanism by which private requirements are translated into public infrastructure.

Salim’s position across company work, standards and community forums gives him influence in that translation. It does not give him ownership of the result. The value of the role lies in maintaining conversations between groups that use different definitions of completion: an RFC editor wants a coherent specification; a kernel reviewer wants a safe interface; a hardware engineer wants implementable primitives; an operator wants predictable failure behaviour.

The sustainability test is whether knowledge spreads beyond the people currently paid to hold it. Documentation, selftests, public presentations and mentorship turn employer-funded effort into a community asset. Without them, open code can remain effectively proprietary because only one team understands how it works.

P4TC is still early enough that its labour structure is part of the technical risk. A small group can move quickly and maintain conceptual unity. It can also become a bottleneck. Broader participation may slow design decisions but improve the chance that APIs survive changes in employer priorities. The balance cannot be solved by declaring the project open. It must be built through repeatable review and shared operational evidence.

Netdev review is the social control plane

Linux networking is often described through code and APIs, but its continuity depends on review communities. Patches are argued on mailing lists, tested against current trees and revised in response to maintainers. Conferences such as Netdev bring kernel developers, researchers, vendors and operators into the same technical conversation.

Salim is a central organiser in that community, and Mojatatu has supported the conference. This role matters because emerging ideas such as P4TC need more than a repository. They need a place where implementers can compare assumptions, expose performance results and hear from operators who will carry the failure risk.

Community leadership does not confer unilateral kernel authority. Traffic Control changes still pass through subsystem and networking maintainers. Linus Torvalds’s mainline process sits above them. Sponsorship supports events but does not buy merge decisions. This separation is essential to the legitimacy of open infrastructure.

The process can nevertheless concentrate influence. Maintainers with long historical knowledge can identify risks that occasional contributors miss. They also have limited time. A complex patch series can stall because reviewers cannot absorb it. Employer-funded teams have more capacity to respond than independent developers. Public review makes the imbalance visible but does not eliminate it.

P4TC’s breadth will test that system. It touches kernel packet processing, user-space APIs, compilers, tests and potentially hardware offload. Review must be distributed among specialists, yet the final interface needs coherence. A project can accumulate technically correct pieces that do not form a maintainable whole.

Mentorship is one response. Salim’s involvement in P4 community programmes and Netdev helps create contributors who understand both language concepts and kernel conventions. This is not a side activity. Succession risk is real in mature subsystems. If only a few people can review the interaction between tc, Netlink and P4, the feature’s long-term support is fragile.

Transparent governance also helps operators evaluate maturity. Mailing-list discussion, selftests and release history show whether a feature is actively maintained and how disagreements are resolved. Marketing material can announce programmability; upstream review reveals the cost of making it safe.

The social process is therefore part of the technical architecture. A stable API depends on reviewers who resist shortcuts. Interoperability depends on vendors willing to test. Production adoption depends on operators reporting failures. Salim’s career illustrates how much network programmability is governed by these relationships rather than by one design document.

Open interfaces move lock-in rather than removing it

P4TC is often framed as an open alternative to proprietary packet-processing systems. That description is directionally useful but incomplete. An operator may avoid a vendor-specific CLI and express policy through P4 and Netlink. It can still become dependent on a compiler, kernel version, driver, hardware target and orchestration system.

The relevant question is whether those dependencies are inspectable and replaceable. Open source allows an organisation to review code and build its own version. In practice, maintaining a kernel dataplane and compiler requires specialised expertise. Most operators will rely on distributions, vendors or integrators. The economic advantage comes from competitive support and shared interfaces, not from the fiction that every user can become a maintainer.

A common control surface can improve bargaining power. Applications can target Linux rather than one appliance. Vendors can implement offload without owning the entire policy model. Researchers can test new pipelines on widely available systems. These benefits are meaningful even when perfect portability is absent.

The cost shifts toward integration. Operators must qualify compiler and kernel combinations, verify offload, monitor state and plan upgrades. The more programmable the system becomes, the more configuration behaves like software. Version control, code review and testing are not optional practices borrowed from developers; they are network-safety mechanisms.

The ForCES experience warns against assuming that openness and standardisation produce adoption automatically. A strong ecosystem needs maintainers, documentation, test infrastructure and commercial reasons for vendors to support the interface. If major hardware paths remain incomplete, operators may choose proprietary SDKs despite the lock-in because the performance and support are clearer.

P4TC’s strongest position may therefore be in environments that value Linux integration more than target independence: software appliances, edge systems, research platforms and hosts where kernel lifecycle is already managed. Broader adoption would require convincing evidence that the same policies can move across hardware and distributions without costly re-engineering.

Salim’s contribution is not the promise of a lock-in-free network. It is the sustained attempt to make the control boundary public and programmable. That is a more defensible goal. It gives operators a basis for demanding stable semantics and alternative implementations, even when the underlying execution remains specialised.

Success means operators no longer have to guess

A headline benchmark will not settle P4TC’s future. The decisive evidence will be a stable operational path from a P4 description to a provisioned Linux pipeline, a runtime controller and, where available, hardware offload. Each layer must report what it accepted, where execution occurs and what happens when part of the request cannot be honoured.

Traffic Control gives P4TC an installed architecture and a large user base. It also supplies the compatibility obligations accumulated by scripts, drivers, distributions and appliances. Netlink attributes, object lifecycles and error behaviour cannot be treated as temporary scaffolding once user space depends on them.

Salim’s earlier work explains why this discipline matters. ForCES showed that a rigorous specification does not create adoption by itself. Netlink showed how an extensible control channel becomes a durable public contract. Traffic Control showed that composable actions can support many uses while making execution paths harder to read.

The project will look like infrastructure when operators can provision a versioned pipeline, update it under load, inspect counters from the actual execution path, recover after a controller or driver failure and roll back without reconstructing intent from logs. Independent compilers and controllers should reach the same result, while drivers should state plainly which behaviour they preserve.

Salim neither invented Linux Traffic Control alone nor decides its future unilaterally. His influence lies in the continuity between subsystem design, standards work, review and community maintenance. P4TC’s observable test is whether that continuity can produce an interface whose meaning survives beyond the people currently building it.