Offloading L7 Policies to the Kernel Laurin Brandner
Ayush Mishra
Sebastiano Miano
ETH Zürich [email protected]
ETH Zürich [email protected]
Nvidia [email protected]
Aurojit Panda
Gianni Antichi
Laurent Vanbever
Politecnico di Milano [email protected]
ETH Zürich [email protected] eBPF Data Plane IPC Acceleration
1
User Sp.
Service meshes have recently emerged as the de-facto standard for deploying microservices. Conceptually, they provide a uniform abstraction for inter-process communication (IPC) between services by implementing common networking mechanisms—such as encryption, routing, and load balancing—and by allowing these mechanisms to be configured and composed through high-level policies. Supporting these policies, however, comes with a significant performance cost, since service meshes interpose proxies (“sidecars”) on the data path, leading to numerous context switches. This paper presents L7FP, a fast path for service meshes which can enforce the vast majority of application-layer policies seen in the wild directly in kernel space. Given high-level policies, L7FP automatically synthesizes an eBPF-based data plane which enforces them in the kernel. L7FP accelerates existing microservices without any code modification, and transparently falls back to existing service proxies (the slow path) for the few unsupported policies. We fully implemented L7FP, with support for both TLS and HTTP/2. Compared to state-of-the-art service meshes, L7FP reduces the median request latency of realistic applications by up to 6× while sustaining 3× more throughput.
Full Acceleration No Acceleration
Service Proxy
Socket Kernel Space
arXiv:2605.31084v1 [cs.NI] 29 May 2026
Abstract
Web Server
Socket
Socket
Network Stack NIC
Loopback
Figure 1. By default, service proxies route inter-pod traffic through the loopback device (blue line). State-of-the-art service meshes optimize IPC by rerouting the traffic using eBPF (orange line). L7FP offloads L7 policy enforcement to the kernel, eliminating the service proxy from the critical path (green line).
Introduction
Modern data center applications are no longer monolithic: they are assembled from swarms of microservices [7, 23, 32, 35] or “pods”, stitched together by service meshes [40, 56]. Service meshes simplify development by abstracting away the networking layer, making applications easier to deploy and manage. This approach has fueled the widespread adoption of platforms such as Istio [29] and Linkerd [42]. A key component of these service meshes is the service proxy, also known as “sidecar”. A service proxy acts as the data plane of the service mesh: it processes all the inter-pod traffic and enforces policies defined at the transport (L4) and/or application layer (L7). For example, Istio relies upon Envoy [21]—a popular service proxy—to enforce L4 load balancing or L7 request authorization. While convenient, service proxies can slow down a service mesh significantly: previous studies have shown that they can increase request latency by up to 185% [68], and increase CPU utilization by 41%–92%. This overhead can be
traced back to two main sources: (1) Service proxies execute highly general code and can enforce any conceivable policy. This generality simplifies deployment but carries substantial performance overheads. As we show (c.f. §2), these bloated processing times can contribute to more than half of the overhead of proxies like Envoy. (2) Service proxies increase the amount of inter-process communication (IPC), which in turn increases both CPU requirements and processing time. We visualize this extra cost in Figure 1 (see the blue line): each message that the web server receives is routed through the loopback device, traversing the network stack and crossing the user-kernel-boundary three times. To reduce this overhead, state-of-the-art service meshes such as Cilium [16] and Calico [11] have mainly relied upon two techniques. The first technique aims at minimizing the IPC cost by bypassing the network stack using eBPF [20] (see the orange line in Figure 1). In practice, though, such bypasses tend to yield limited performance improvements 1
Arxiv, 2026
Brandner et al.
because the bottleneck tends to be—as we show in this paper— the message processing time in the service proxy. Acknowledging this limitation, the second technique (illustrated in green) aims at removing the service proxy entirely from the critical path by offloading L4 policies to the kernel [11, 16]. While extremely effective, this technique only applies to L4 policies, meaning the user space service proxy still needs to enforce L7 policies. Unfortunately, L7 policies also constitute the bulk of the policies in modern deployments. As an illustration, Alibaba reports that the vast majority of their customers (between 80% to 95%) use L7 policies in their service mesh [65]. A natural, yet still open, question is therefore: Is it practical to offload L7 policies to the kernel? We answer this question in the affirmative and show that offloading L7 policies is both practical and dramatically improves the performance of realistic workloads. More specifically, we describe a kernel-based fast path—named L7FP— that can transparently accelerate the most common L7 policies (e.g., HTTP-based). It achieves this by jointly addressing both main sources of overhead: generality and IPC cost. We implement our fast path in eBPF. Despite eBPF-based facilities to process application-layer traffic in the kernel [36, 38], and previous work demonstrating eBPF’s potential to do so [39], this approach has remained impractical for HTTPbased policies due to eBPF’s stringent limitations. In this paper, we present eBPF-compliant techniques that enable the enforcement of complex L7 policies in the kernel. Given a description of an L7 policy, L7FP first automatically synthesizes a highly optimized and policy-specific data plane in eBPF and loads it into the kernel. As we show, L7FPsynthesized code is able to process in the kernel the vast majority (89%) of the use cases found in 2417 open-source projects. In doing so, L7FP completely eliminates all IPC overhead that would typically arise, similarly to L4 offloads. In the unlikely case a policy cannot be enforced in the kernel, L7FP transparently falls back to the user space service proxy. We stress that existing service proxies do not need to be modified to benefit from L7FP. We implemented L7FP and demonstrate its practicality by speeding up state-of-the-art service proxies such as Envoy, and show that L7FP significantly improves performance. Under realistic conditions, L7FP reduces the median request latency of state-of-the-art service meshes by up to 6×, and the 99𝑡ℎ -percentile by 4×, while serving up to 3× more traffic. To sum up, we make the following contributions:
It overcomes the drawbacks of state-of-the-art solutions by significantly improving request latency and throughput. 3. We implement L7FP with support for HTTP/1.1, HTTP/2, TLS and six popular policies. We evaluate its performance on synthetic and realistic workloads and share the code to foster reproducibility.
2
The Case for an L7 Fast Path
In this section, we make the case for enforcing L7 policies directly in the kernel. We begin with a brief background on how popular service proxies such as Envoy [21] operate before quantifying their main sources of overhead. We show that, with or without IPC acceleration, Envoy imposes significant performance overheads. We then discuss what it would take to reduce these overheads and use those insights to motivate L7FP’s design. 2.1
Background: Service Proxies
Services proxies act as the data plane of service meshes and are responsible for handling all the inter-pod traffic. Proxies are typically deployed either per pod (e.g., a sidecar in each pod) or per node (one proxy handling traffic for multiple applications on the same host). A service policy specifies how the proxy should handle the traffic. Typical service policies relate to inter-pod routing, protocol bridging, and security (e.g., authorization). As such, they tend to operate either at L4 (e.g., forwarding a message from one port to another) or at L7 (e.g., routing an HTTP request to a particular pod based on method, path, or headers). 2.2
Identifying the Overhead Sources
To measure the overhead of services proxies, we deploy the Social Network application from DeathStarBench [23] while enforcing a minimal L7 policy that routes traffic based on the HTTP path. We measure the average request latency at 1,500 req/s in four different configurations.1 In the first configuration, Envoy, we measure the request latency of the application with a single (per-node) instance of Envoy (the blue line in Figure 1). In the second configuration, L4 fast path, we also use Envoy, but accelerate it with an L4 fast path that reduces IPC cost by short-circuiting traffic at the socket layer (the orange line in Figure 1). In the third configuration, L7FP, we enforce the L7 policy in the kernel, removing Envoy from the request path (the green line in Figure 1). We compare these three configurations against the lower bound, which represents the application without Envoy, but its traffic accelerated with the L4 fast path.
1. We make the case for processing L7 policies in kernel space and demonstrate that eBPF is mature enough to implement the most commonly used L7 policies observed in the wild. 2. We introduce L7FP, an eBPF-based fast path for any service proxy that processes L7 policies in user space.
1We choose this rate because, in our setup, it exercises the full application without exceeding the maximum throughput of all configurations (see §5)
2
Offloading L7 Policies to the Kernel
Description Parsing HTTP in the service proxy. Processing the message and enforcing the policy. I/O syscalls like send and recv. Remaining portion of the request latency, that consists mostly of the application’s processing time.
Parsing
IPC
Other
- 17%
6
- 46%
4
lower bound
2 0
Table 1. Generality makes parsing and policy enforcement inefficient. IPC costs arise because the policy is enforced outside of the pod’s process.
Envoy
L4 Fast Path
L7FP
Figure 2. Protocol parsing, policy enforcement, and IPC are the main sources of overhead that dictate Envoy’s performance. L7FP optimizes these inefficiencies simultaneously, resulting in a 46% lower request latency.
We decompose the per-request latency into the three major sources of overhead identified by MeshInsight [68]: protocol parsing, policy enforcement, and IPC.2 We label the remaining time that consists mostly of the application’s processing time as Other (c.f. Table 1). Figure 2 shows the result. Envoy adds 3.4 ms per request, which is 47% of the overall 7.2 ms average request latency at this load (lower bound without Envoy: 3.7 ms, on our testbed described in §5). Adding the L4 fast path reduces per-request latency by 17%. Across these configurations, we see that Envoy’s overhead is dominated by protocol parsing, followed by IPC. Protocol parsing accounts for 1.8 ms (54%) of Envoy’s total overhead. Moreover, even with a minimal policy, enforcement makes up another 7%. On the other hand, by employing a specialized data plane in kernel space, L7FP reduces the total overhead to 0.12 ms—a 96% reduction. Similarly, IPC accounts for 0.5 ms (15%) of Envoy’s overhead. The L4 fast path reduces this cost by bypassing the network stack—also shrinking the Other remainder—for an overall reduction of 17%. Again, by enforcing the policy in the kernel, L7FP eliminates any proxy-induced IPC. 2.3
Policy Enforcement
8 Latency [ms]
Component Parsing Policy Enforcement IPC Other
Arxiv, 2026
The following paragraphs discuss why L7FP’s data plane can profit from specialization and what the benefits of offloading that data plane to the kernel space using eBPF are. Specializing the data plane. Service proxies like Envoy employ one single, complex data plane that is designed to support every policy on every protocol. This results in complexity that is unnecessary in most cases, which in turn leads to expensive policy enforcement and protocol parsing. L7FP takes the opposite approach: It synthesizes a specialized data plane that is specific to the service policy. Program specialization is a well-known approach that simplifies code by fixing variables to known values [9, 46]. This makes otherwise necessary complexity redundant, allowing L7FP to eliminate dead code, use more efficient data structures, and compile policy-specific invariants directly into the binary. Exploiting these optimization opportunities renders the data plane simpler and ultimately, more efficient. Offloading the data plane. As previously noted, IPC overhead arises because the policy is enforced outside of the pod’s process. This results in a number of additional context switches that grows linearly with the call graph size of each request. By offloading the data plane to the kernel, these rising IPC costs can be avoided. Despite this, the experiment above suggests that a specialized data plane in user space might be useful, too. Kernel offloading is commonly done with two different techniques: Kernel modules or eBPF [20]. In recent years, eBPF has become increasingly popular as it facilitates kernel offloads significantly. With the Compile Once-Run Everywhere (CO-RE) feature, eBPF achieves portability across different architectures and kernel versions. This simplifies development and lowers maintenance costs. In the context of service proxies, eBPF has another advantage: Its interface makes it easy to dynamically deploy new policies. However, using eBPF to offload the data plane comes with its own set of limitations. Most importantly, the Linux kernel
Addressing the Major Overheads
The experiment above illustrates that the performance of service proxies, even for simple L7 policies, is shaped by multiple factors. Protocol parsing dominates overall cost, while IPC overheads make a secondary but measurable contribution. Maximizing performance, therefore, requires jointly optimizing both aspects. In this work, we propose L7FP, a fast path for L7 policies. It specializes the data plane to the policy and thus avoids unnecessary work when parsing the protocol and enforcing the policy. Moreover, it offloads the data plane to kernel space, allowing it to eliminate any IPC overhead that would arise from enforcing the policy outside of the pod’s process. Together, these optimizations reduce the Social Network’s request latency by 46% (c.f. Figure 2). 2 To reduce attribution error, we instrument the proxy with in-process atomic
counters rather than relying on eBPF; the additional measurement overhead is negligible relative to the reported magnitudes. 3
Arxiv, 2026
Brandner et al.
Category Description CustomExtending Envoy’s off-the-shelf functionality ization with custom modules and external pods. Protocol Bridging between protocols and protocolspecific data extraction. Routing Routing, measuring, load balancing, and circuit-breaking traffic. Security Authenticating, authorizing, encrypting, and signing traffic. Table 2. Service proxies are most commonly used to route traffic, but also to enforce security policies or act as bridges between protocols.
Kernel changes unnecessary Occurrences
6K
Kernel changes required 2%
4K 2K
8%
13%
83%
0
Custom- Protocol Routing Security ization
Figure 3. The most popular L7 policies can be implemented in eBPF and do not require kernel changes. We conclude that eBPF is sufficient to offload the most popular L7 policies to kernel space. In the following section, we discuss how L7FP accelerates applications in detail.
verifies the safety of an eBPF program by performing an exhaustive execution path traversal [66, 67] before it is loaded into its address space. This process becomes intractable for programs with complex control flows, hence limiting the complexity that can be offloaded with eBPF. Moreover, the eBPF runtime is event-based, making it impossible for an eBPF-based data plane to send messages on its own accord. This renders the offload of some L7 policies impractical. A common practice to circumvent these limitations is the modification of the kernel with a kernel module. It is not verified and can execute arbitrarily complex programs. However, as we will show, the most popular L7 policies are simple enough to offload with eBPF. We show this by analyzing the L7 policies used in 2417 open-source projects on GitHub. More specifically, we analyse 4699 distinct Envoy configuration files, and classify all containing L7 policies in one of the categories listed in Table 2. We manually inspect each policy to determine if it can be implemented in eBPF without kernel changes. The results are shown in Figure 3. Our analysis shows that 89% of all deployed L7 policies can be implemented without any kernel changes. However, there are some exceptions. 83% of customization policies extend Envoy’s functionality with a custom runtime like WASM, Lua, or Go. Such policies must be transpiled to the eBPF instruction set architecture (ISA) and are unlikely to pass verification without careful consideration. 8% of the protocolrelated policies apply (de-)compression on the HTTP body. 2% of the routing policies are not event-based. For example, health checking requires the host to send messages to the upstream pods on a regular basis. Finally, 13% of security policies make use of cryptographic hash functions that are currently not supported by eBPF3 . eBPF is a continuously evolving platform with more features added every day. As such, we expect the number of policies that require kernel changes to shrink in the future.
3
Design
L7FP enforces the vast majority of the L7 policies found in the wild (Figure 3) directly in the kernel using a streamlined, eBPF-based data plane. For the (few) unsupported policies, L7FP automatically and transparently redirects the corresponding requests to existing service proxies, such as Envoy. In many ways, L7FP’s design follows a classical SDN split [45, 51] composed of a data plane and a control plane, alongside with an interface between the two. The key difference is the level of abstraction at which L7FP functions: L7FP’s data plane forwards incoming L7 messages onto sockets, rather than packets onto ports. In this section we provide an overview of L7FP’s data and control plane using a running example (Figure 4) in which L7FP accelerates an application composed of two pods, A and B, and a service proxy. We assume that the application serves two endpoints, /feed and /admin, and that the service mesh is configured with two L7 policies: Match
Policy
/feed
1. add accept header 2. route to pod B
/admin
1. run a custom authorization script 2. route to pod B
The first policy adds an accept header to /feed requests before routing them to pod B. The second policy mandates the requests to /admin to be authorized using a custom script running on the service proxy and that cannot execute in the kernel, e.g. because it would require an in-kernel interpreter. This is a typical deployment where maintenance endpoints are secured with a company-wide authorization script. As Figure 4 shows, L7FP eventually ends up enforcing /feed requests entirely in the kernel. Conversely, it ends up
3 Note that the Linux kernel already implements an extensive crypto API [18]
and starting from version 6.10, exposes limited functionality to the eBPF runtime. In §4, we discuss how to extend the existing interface with minimal kernel changes. 4
Offloading L7 Policies to the Kernel
User Space
L7FP Fast Path
Container Slow Path
A
Arxiv, 2026
deterministic finite automaton (DFA). The data plane keeps track of the protocol each connection is currently using, and selects the DFA accordingly. It uses this DFA to parse the data in the receive queue and identify individual messages. It is possible that this data does not yet contain an entire message. In that case, the data plane waits for more data to arrive. If a message can be identified, it extracts all policyrelevant information from the message. To this end, the data plane feeds the message byte-by-byte to the DFA. The DFA then indicates the relevant byte ranges to the data plane, which it stores into the header vector 𝐻 . This data structure holds the extracted information and other metadata of one L7 message. L7FP constructs each DFA on startup for the given policy. It encodes them as a matrix of integers and loads them into the data plane. Additionally, it defines a header vector that can hold all policy-relevant information. The procedures that execute the DFA remain the same across service policies. In the example above, the data plane in Figure 5 only needs to know the HTTP path to enforce either policy. Thus, the header vector consists of a single pointer to the located path, along with metadata like the length of the header block.
Hardware Conn. Pool Miss B
Service Proxy
Kernel Space
Control Plane /feed
Data Plane /admin
NIC
Figure 4. The fast path processes L7 policies in the kernel. The slow path falls back to the service proxy. routing /admin requests onto an open socket to the service proxy, as these requests cannot be authorized in the kernel. 3.1
Data Plane
Match. This stage selects the appropriate policy to enforce. It consists of a sequence of comparisons between the header vector 𝐻 and the policies’ match criteria. The service policy determines the order of this sequence, which encodes the priority for each endpoint’s policy. L7FP synthesizes this stage as a sequence of if clauses. In the example above, the Match stage in Figure 5 employs two if clauses that compare the extracted HTTP path in the header vector with “/feed”, and “/admin”, respectively.
Given a high-level policy, L7FP automatically synthesizes an eBPF-based data plane and loads it into the kernel. This data plane adopts the Parse-Match-Action paradigm commonly seen in network functions. It intercepts all (ingress, egress, or local) requests to the application, enforces the corresponding policy, and redirects the traffic to the appropriate socket. Figure 5 visualizes the integration into the kernel for the ingress data path. First, at the TCP layer, the kernel manages the TCP state machine and reassembles segments to provide a reliable byte stream. Next, kTLS [37] leverages stream parser (strparser) [38] to delineate TLS records before decrypting them. The decrypted stream then reaches L7FP’s data plane at the socket level (SK_SKB for ingress or egress traffic, SK_MSG for local traffic). It integrates the Parse stage with strparser to delineate application-layer messages. This extracts only the necessary headers to enforce the policies, and stores them into a header vector 𝐻 . Next, the Match stage compares the extracted headers with the policies’ match criteria. This yields the policy that should be enforced, along with the forwarding target for the request. Finally, the Action stage runs a sequence of actions; simple, generic functions that collectively execute the policy. At the end of each action sequence, the data plane performs a connection pool lookup for a previously established socket to the forwarding target. Conceptually, this connection pool is akin to the forwarding table of an SDN switch. The following paragraphs discuss for each stage first their functionality at runtime, and then how L7FP synthesizes them.
Action. This stage executes a sequence of actions required by the policy. Each action is a simple function, as listed in Table 3. They are generic and do not change across policies. Every action sequence terminates with a drop or forward action. The latter action queries the connection pool for an open connection that it can use to forward the message. L7FP synthesizes this stage by first identifying which policies it can offload to kernel space. It replaces unsupported policies with a route policy to fall back to the service proxy. Next, it generates code for each policy using a template that defines its action control flow with policy-specific arguments as placeholders. During synthesis, L7FP replaces these placeholders with the actual data from the policy. It inserts the resulting code into the data plane code, along with the implementation of each action. This yields the final eBPF code, that can be compiled and loaded into the kernel. In the example above, for the /feed request, the data plane adds the accept header with get and write before routing it with get and forward. Likewise, for the /admin request, it performs get and forward to route it to the service proxy. Figure 6 visualizes the synthesis of the /feed policy. It shows that the service policy requires L7FP to add an accept
Parse. This stage extracts policy-relevant information from each message. It consists of multiple, protocol-specific 5
Arxiv, 2026
Brandner et al.
Parse strparser
TCP
Match
Action
strparser
kTLS
/feed
get
write
get
/admin
get
forward
forward
Socket A
H
Socket SP
Figure 5. The data plane parses the message and returns a header vector. Subsequent actions enforce the L7 policy based on this data structure. Action compare read/write en-/decode en-/decrypt
Description Compares two data values. Reads/writes a segment of the message. En-/decodes data with a given scheme. En-/decryptes data with a given scheme. hash Hashes data with a given scheme. get/set Manage state in a global data structure. This makes it possible to share state between flows, or read it from user space. forward Forwards the message to a downstream, upstream, or proxy socket. drop Drops the message. Table 3. Actions are the building blocks of L7 policies.
Service Policy /feed Header Mutation: add accept: */* Route: to 172.18.0.3
Template u32 idx = get(hdr_vec, "len"); char *hdr = " HDR \r\n"; write(idx, hdr); struct sock *dest = get(conn_pool, IP ); forward(dest);
Data Plane get {...} write {...} forward {...} feed { header mutation route }
Figure 6. L7FP synthesizes the Action stage with predefined policy templates. mutation template shown in Figure 6 is HTTP/1.1 specific. This can be seen by the plain text hdr variable that terminates with “\r\n”. L7FP is extensible, and new policies can be implemented by providing L7FP with new templates. 3.2
header before routing the request to 172.18.0.3, the IP address of pod B. L7FP uses the header mutation policy to append the new header. This policy first calls the get action to retrieve the insert location of the new header, and then calls write to insert the string into the message. Similarly, it uses the route policy to forward the message to pod B. This policy also first calls get to query the connection pool, and then calls forward to perform the redirection. L7FP replaces the accept header with the HDR placeholder in the header mutation policy, and 172.18.0.3 with the IP placeholder in the route policy. This results in code that is almost ready to compile. In a final step, L7FP concats the specialized templates into a single function, and inserts that function into the data plane code. The data plane code contains the implementation of the actions and the execution engine for the parsing stage. The synthesis of the /admin policy looks very similar. Because L7FP cannot execute custom scripts in eBPF, it replaces the policy with a route policy, into which it inserts the IP address of the service proxy. Note that policy templates may be L7 protocol specific. In the case of HTTP/2, it is also necessary for L7FP to be able to upgrade connections from HTTP/1.1, i.e. switch between policy implementations. To account for this, L7FP generates the header mutation code with two templates, keeps state at runtime on the currently used protocol, and calls the appropriate action sequence accordingly. Note that header
Control Plane
Given that connection establishment is not possible in eBPF, L7FP relies on a control plane to maintain the connection pool. It is empty on startup and lazily replenished during runtime. When a connection pool miss occurs, the L7FP data plane automatically forwards the request to the control plane. The control plane in turn establishes a new connection to the forwarding target, inserts it into the connection pool, before letting the data plane forward the request. These connections remain open and are reused until the peer closes them. In this regard, the control plane manages connections to the service proxy like for any other forwarding target.
4
Implementation
This section describes the implementation of L7FP. We implement the control plane in approximately 4K lines of Rust code, the data plane in 2K lines of C code. In the following paragraphs, we outline the details of the Parse-Match-Action architecture, and some challenges of implementing it in eBPF. 4.1
The Parse Stage
We implement the Parse stage for HTTP/1.1 and HTTP/2. L7FP is extensible and new protocols can be added by designing a DFA construction for the respective protocol. Parsing TLS-encrypted traffic. A common use case of service proxies is TLS. Service meshes rely on the proxy to 6
Offloading L7 Policies to the Kernel
Arxiv, 2026
Policy Route Load Balancer JWT
Actions Description get, forward Redirects the message based on the HTTP headers. read, hash, get, Load balances a message using the Ketama [33] scheme. It hashes a message property, e.g. an HTTP header, with xxHash [34] and uses it to index a list of upstream pods. forward read, decode, hash, Authenticates JSON Web Tokens (JWT) with the HS256 authentication scheme and get, compare, drop authorizes the request based on the issuer and audience claim. RBAC read, get, compare, Enforces network-wide Role Based Access Control (RBAC) policies by white-listing drop port ranges, source IPs, HTTP paths, etc., for a specific endpoint. Telemetry read, get, set Records statistics of the requests and responses. Mutation get, write Adds, removes, or modifies existing HTTP headers. Table 4. L7FP supports six popular policies, implemented for HTTP/1.1 and HTTP/2.
Routing HTTP/2. The HTTP/2 protocol compresses headers [28] using a Huffman encoding and a cache that allows the sender to transmit references to previously used headers. While the former is stateless, the latter renders the header compression stateful. This poses a problem, as L7FP cannot forward header references to a different receiver without dereferencing them first. To avoid this, L7FP requires all pods to disable header caching. This is a common feature of HTTP/2 libraries [5, 44]. We will show in §5 that despite this, L7FP accelerates HTTP/2 significantly. Note that Huffmanencoded headers are fully supported and can remain enabled. Moreover, L7FP routes HTTP/2 stream-wise: The header frame at the start of the stream dictates the forwarding target of the following frames. However, not all frame types have a clear destination. For example, a push promise notifies the peer of a stream prior to sending the header frame. Likewise, the flow control frame can be connection-wide. If the forwarding target is unclear, the data plane forwards the frames to the control plane. Future versions of L7FP cache push promises and split up flow control frames.
authenticate the application to the client, or authenticate two communicating pods with mutual TLS (mTLS). L7FP terminates TLS and parses encrypted traffic directly in the kernel. We highlight two key implementation details required to achieve this. First, L7FP offloads TLS to the kernel with kTLS [37]. To this end, the control plane performs the TLS handshake upon connection establishment, before passing the cryptographic connection state to the kernel. Second, L7FP attaches the data plane to the SK_MSG or SK_SKB hook on each socket. It uses the former to process and redirect local traffic before the kernel encrypts it. It uses the latter to process ingress traffic after the kernel decrypts it, or egress traffic before the kernel encrypts it, respectively. 4.2
The Match Stage
L7FP’s data plane matches HTTP headers with basic string comparison functions. Future versions of L7FP can extend this with non-backtracking regex patterns, for example. 4.3
The Action Stage
Guided by our policy survey (see Figure 3), GitHub repositories [15, 31] and previous work [58, 65], we implement six policies (c.f. Table 4): two routing policies, two security policies, telemetry, and one traffic mutation policy. L7FP’s architecture is extensible, allowing users to add new policies with minimal effort.
Managing Connections. L7FP manages open connections with the connection pool. We implement it with an eBPF hash map that maps IP addresses to queues of sockets. This design gives the data plane the flexibility to dynamically adapt the multiplexing behavior for each connection. For example, for HTTP/2 connections, the data plane only pops the socket out of the queue if the maximum number of concurrent streams is reached, and does not append it back to the queue until a stream closes. In the meantime, L7FP forwards requests onto the next socket in the queue.
Encoding and Hashing. Actions like hash, en-/decode, and en-/decrypt are inherently impractical to implement directly in eBPF. While Linux kernel version 6.10 provides kfuncs [17] to en- and decrypt data, similar functions to hash or encode arbitrary data are missing. However, popular policies like ring load balancers rely on non-cryptographic hashes functions to distribute traffic evenly across servers, and JSON Web Token (JWT) [4] depend on base64url. Fortunately, the kernel already implements many commonly used hashing and encoding schemes [18, 34], the eBPF runtime just cannot access them. L7FP employs a minimal kernel module (172 lines of C code) which exposes this functionality to the eBPF runtime.
5
Evaluation
In this section, we assess the performance of L7FP along three dimensions. First, in §5.2, we analyze the performance benefits that L7FP provides. We show that for a realistic workload, L7FP can improve the median request latency of state-of-theart service meshes by up to 6× while sustaining up to 3× more traffic. Second, in §5.3, we evaluate L7FP’s overhead in the worst case, where all traffic must be processed by the 7
Arxiv, 2026
Brandner et al.
service proxy and show that it still outperforms Envoy for requests with headers smaller than 6.8 kB. For requests that are larger than this, the parsing overhead outgrows the IPC acceleration. Finally, in §5.4, we examine how L7FP scales with increasingly complex policies. We find that while L7FP’s performance degrades faster than Envoy’s, its throughput remains at least 39% higher, even when Envoy is accelerated with an L4 fast path. 5.1
Envoy: This deployment uses Envoy without any acceleration. It routes traffic through the loopback device. L4 Fast Path: This deployment reduces the IPC costs of Envoy with an eBPF program at the socket level. The eBPF program reroutes the traffic so that the network stack is bypassed. This configuration replicates the data path of state-of-the-art service meshes [11, 16]. Policies. Based on the policy survey (see Figure 3), GitHub repositories [15, 31] and previous work [58, 65], we specify a set of policies to benchmark L7FP in a diverse environment. It is designed to exercise all components of L7FP’s data plane and includes application-layer policies like RBAC, JWT, routing, and traffic telemetry. In §5.4, we will also evaluate L7FP’s performance as a function of how complex a policy is. We define a policy as being more complex if it parses and processes a large amount of data, and/or requires more instructions to enforce.
Methodology
Applications. We evaluate L7FP with three realistic and one synthetic workload. We use Docker Compose to spawn and configure each application. Social Network: The Social Network is a realistic application from DeathStarBench [23] that uses Thrift RPC [64], which we configure to use HTTP/1.1. We generate load with TLS-encrypted /wrk2-api/post/compose requests. Media Service: The Media Service is realistic application from DeathStarBench [23] that uses Thrift RPC, which we configure to use HTTP/1.1. We generate load with TLSencrypted /wrk2-api/review/compose requests. Hotel Reservation: The Hotel Reservation is realistic application from DeathStarBench [23] that uses gRPC [25] over HTTP/2. We disable header caching when benchmarking L7FP, but leave it otherwise enabled. We tested both configurations and found that in our setup, the difference is negligible. We generate load with TLSencrypted /recommendations requests. Echo Service: The Echo Service is a synthetic application consisting of two pods, one frontend, and a single echo pod. For this workload, we send a 100 B long HTTP/1.1 request to the frontend which forwards it to the echo pod before responding. This emulates small applications with minor IPC overhead.
Testbed. We evaluate L7FP on two nodes, one that generates the traffic using k6 v1.1.0 [24] and the other that hosts the application. The first is equipped with a 24-Core Intel Xeon CPU E5-2670 v3 (2.3GHz), while the latter has a 20Core Intel Xeon CPU E5-2670 v2 (2.5GHz). They both have 270GB RAM and run Ubuntu 22.04.5 LTS, Envoy v1.34.0, and Docker v28.2.2. The machine that hosts the service is running Linux kernel v6.16.12. All experiments are performed on bare metal, with TurboBoost and dynamic CPU frequency scaling disabled to reduce measurement variance. 5.2
How Fast Is the Fast Path?
We first assess the best-case scenario, where all messages are processed on the fast path (i.e. in the kernel). We deploy the three realistic applications with their own policies:
Note that DeathStarBench’s frontend endpoints only support HTTP/1.1. We perform the experiments accordingly but emphasize that L7FP fully supports HTTP/2 + TLS, too. Service Proxies. For all experiments, we deploy Envoy [21], a state-of-the-art service proxy typically used with Istio [29]. However, unlike Istio, we deploy Envoy on a per-node basis, i.e., there is only one service proxy for the entire service mesh. For the evaluation presented in this section, we expect a per-node deployment to always be faster than a per-pod deployment. We did not compare against other approaches [12, 57] that break the service proxy abstraction and enforce policies within the application’s process because they are closed-source. L7FP also runs on a per-node basis. Its data plane operates from the socket level and bypasses Envoy completely for the supported policies. For an unsupported policy, L7FP routes the traffic to Envoy. We compare L7FP against two Envoy configurations:
Application
Description
Social Network
1. authorize the JWT in the Authorization header 2. add the x-processed-by header 3. route based on HTTP path
Media Service
1. enforce 50 RBAC policies 2. add the x-processed-by header 3. route based on HTTP path
Hotel Reservation
1. record request telemetry 2. add the x-processed-by header 3. route based on HTTP path
We use a testing regime that sends requests at an increasing rate (closed model) beyond the maximum throughput of the respective application. More specifically, the regime takes 200 s and scales the incoming request rate up to 5K req/s for the Social Network and the Media Service, and up to 8
Offloading L7 Policies to the Kernel
L7FP
Arxiv, 2026
at parsing messages, and enforces the policy without IPC costs. This yields significant performance improvements. Compared to the L4 fast path, L7FP reduces the median request latency of the Social Network by 10×, the Media Service by 2.5×, and the Hotel Reservation by 6×. As a result, all applications serve more traffic, too. Compared to the L4 fast path, L7FP serves up to 49%, 38%, and 3× more traffic. The performance benefits become particularly significant for applications with complex HTTP/2 data planes. HTTP/2 stacks employ expensive state management and coordinate with the peer using control messages. L7FP requires little state, and can forward most of the control messages without processing them.
Envoy
L4 Fast Path Social Network
1 113/132
CDF
0.8 0.6 58/70
5.6
0.4 0.2 0
Throughput [req/s]
4K 68
3.6K
3K
1K 0K
50 100 150 Latency [ms]
2.4K 2.2K
2K
0
100 200 Time [s]
Optimizing IPC alone is not enough. State-of-the-art service meshes improve the performance of L7 policies by optimizing IPC. As Figure 7 shows, this yields only minor performance benefits. For the Social Network and Media Service, it serves up to 15% more traffic, for the Hotel Reservation, which is much more overloaded than the other two applications, the throughput improvement is negligible.
Media Service 87
121/137
CDF
0.8 0.6 26
67/81
0.4 0.2 0
0
Throughput [req/s]
1
2.3K 2K
2K 1K 0K
50 100 150 Latency [ms]
3.2K
3K
5.3 0
Next, we assess the worst-case scenario, where all messages are processed on the slow path. In this case, L7FP redirects all messages to Envoy for processing. To this end, we use the Echo Service. It exhibits minimal IPC overhead, which makes the overhead of the slow path the most apparent. We configure L7FP with the following policy:
100 200 Time [s]
Hotel Reservation 12
64/64
CDF
0.6 5.7
37/37
0.4 0.2 0
20 40 60 Latency [ms]
Throughput [req/s]
1 0.8
15.3K
15K
Policy Description
10K 5K 0K
What is the Overhead of the Slow Path?
1. parse HTTP headers with length of 1 𝑘𝐵 to 16 𝑘𝐵 2. match the HTTP headers against the policy 3. route to the service proxy
5.1K
0
In this experiment, we scale the length of the HTTP headers from 1 kB to 16 kB. We increment the header length by 1 kB at a time and repeat the experiment with two different HTTP header compositions. In the first composition, Single Header, we fix the number of parsed and matched headers to one. In the second composition, Multiple Headers, we fix the size of each HTTP header to 1 kB. The load generator establishes 3000 connections and sends as many messages as possible in one minute. Figure 8 summarizes the results.
100 200 Time [s]
Figure 7. L7FP reduces the request latency across every percentile while increasing the throughput. 20K req/s for the Hotel Reservation. We repeat this experiment 30 times to reduce noise. Figure 7 shows the result. On the left, it shows the CDF of the request latency across the entire experiment. On the right, it shows the request completion rate. We found these trends to be consistent with the applications, even if we swapped their respective policies.
L7FP accelerates the slow path too. The number of HTTP headers has a negligible impact on the performance of L7FP. In both configurations, L7FP remains more performant than Envoy for HTTP headers that are smaller than 6.8 kB. However, as the size of the HTTP headers increases, the throughput decreases, e.g., by 11% for 10 kB headers. In this experiment, L7FP’s runtime is dominated by its parsing overhead, which is a function of the number of parsed bytes. For a 1 kB HTTP header, 73% of the runtime
Specializing the data plane improves performance. L7FP optimizes L7 policies by synthesizing a specialized data plane that is specific to the policy. As we will see in §5.4, this data plane is, compared to Envoy, more efficient 9
Arxiv, 2026
Brandner et al.
L7FP
TPut [req/s]
60K
L4 Fast Path Single Header
60K
6.8 kB
40K
40K
20K
20K 4
8
12
16
Header Length [kB]
Envoy
Policy
Description
Multiple Headers
Route
1. 2.
4
8
12
RBAC
1-3. 4.
enforce the Route policy enforce 𝑐 · 100 RBAC policies
JWT
1-4. 5.
enforce the RBAC policy authenticate the signature of a JWT with total length 𝑐 · 3 𝑘𝐵
Mutate
1-5. 6.
enforce the JWT policy remove 𝑐 · 16 𝑘𝐵 bytes from the headers
16
Header Length [kB]
Figure 8. L7FP’s slow path improves the throughput for messages smaller than 6.8 kB. For larger headers, the parsing overhead outweighs the IPC optimizations.
These policies are designed to scale the complexity along two dimensions: the number of actions and the complexity of the individual parsers and actions. To build increasingly complex policies, we can nest actions recursively. As we can see from the policy description, the complexity parameter c affects multiple policy components simultaneously. For example, RBAC[𝑐 = 1] parses one 16 kB-sized HTTP header and enforces 100 RBAC rules. The final policy, Mutate, represents the most complex policy that the current implementation of L7FP can offload (see §4 for a discussion on how to alleviate this limit). Given that the parsing complexity is a function of the total number of bytes parsed and remains largely independent of the number of HTTP headers (§5.3), this experiment uses only one header.
is spent on parsing. This overhead is fundamental, as L7FP must iterate over the full HTTP header to match the message against the configured policy. The remainder of the runtime is implementation-specific and accounts for data copies, string comparisons and eBPF map queries (see §5.4). We want to emphasize that this experiment pushes the ratio between IPC cost and parsing overhead to the extreme. In this experiment, IPC cost is minor with only two pods that process the request. On the other hand, the request sizes are large in comparison to cloud-scale deployments. [59] reports that half of the observed RPC calls in production have a median request size below 1.5 kB, with responses blow 315 B. For requests of this size, L7FP achieves roughly 8% more throughput than Envoy. Finally, it goes without saying that L7FP should not be deployed in a service mesh where it cannot process any message directly in the kernel. Despite this, L7FP can efficiently record traffic telemetry. Future versions can use this data to dynamically (de)active the fast path on a per-connection basis. Thus, we expect L7FP to be able to accelerate a vast majority of workloads, even if in some cases it has to resort to the slow path. 5.4
3.
parse the header with length 𝑐 · 16 𝑘𝐵 match one HTTP header with length 𝑐 · 16 𝑘𝐵 record traffic telemetry
6.8 kB
L7FP’s performance is a function of policy complexity. As shown in Figure 9, we observe the same trend for all four policies. In general, L7FP consistently outperforms both configurations of Envoy. However, this performance gain diminishes as policies become more complex. For example, consider the policy JWT[𝑐 = 0.5], which parses and matches an 8 kB long HTTP header, enforces 50 RBAC policies, and authenticates a 1.5 kB long JWT. With this configuration, L7FP achieves a 59% higher throughput than the L4 fast path. For JWT[𝑐 = 1], this improvement shrinks to 44%. We note that our per-node deployment is an extreme case. Typically, the service proxy’s overhead is multiplied in a perpod deployment because more than two instances process each request. Additionally, as mentioned earlier, [59] reports that half of all RPC calls in their data center have a median request size below 1.5 kB in their production systems, which corresponds to policies with 𝑐 ≤ 0.1. To summarize, for all policies that the current implementation of L7FP is able to offload, it is more efficient than Envoy, even when accelerated with an L4 fast path.
How does the Fast Path Scale?
The previous experiments show that L7FP’s fast path accelerates realistic workloads significantly, and the slow path only induces a slowdown in extreme cases. In this experiment, we validate whether the benefits of the fast path also hold as policies become increasingly complex. As in §5.3, we deploy the Echo Service to minimize IPC overhead, and consequently limit L7FP to rely more on its parsing and processing pipelines for performance gains. We configure the service proxy with four different policies, each of which can be tuned to be more complex via a tuneable parameter c: 10
Offloading L7 Policies to the Kernel
TPut [req/s]
100K 75K
Parsing
Route
RBAC
+57%
+55% +40%
+39%
50K 25K 0K
100K TPut [req/s]
Envoy
L4 Fast Path
Overhead [ms]
L7FP
Arxiv, 2026
75K
0.25 0.5 0.75
1
0.25 0.5 0.75
Complexity
Complexity
JWT
Mutate
+59%
L7FP
IPC
L4 Fast Path +251%
0.5
0
Other Envoy +206%
+877%
0.5 1 Complexity
0.5 1 Complexity
0.5 1 Complexity
Figure 10. The eBPF runtime is less efficient than user space, such that the performance degrades more quickly when enforcing the Mutate policy. Despite this, L7FP still outperforms the L4 fast path by 2.2× in the worst case.
+73% +52%
+44%
50K
1
1
Policy Enforcement
25K 0K
0.25 0.5 0.75 Complexity
1
0.25 0.5 0.75
1
overhead is only 0.30 ms, whereas Envoy’s overhead reaches 0.78 ms for every request (0.68 ms with the L4 fast path). To summarize, eBPF’s runtime is indeed less efficient than that of the user space. Therefore, offloading significantly more complex policies will inevitably lead to a point where the policy enforcement in eBPF is disadvantageous. However, we consider such a policy to be an extreme case that is unlikely to be used in practice.
Complexity
Figure 9. Even for the most complex policies, L7FP improves the throughput of the L4 fast path by at least 39%. For aboveaverage complex policies, the throughput improvement can reach up to 73%.
6
Understanding L7FP’s overheads. The previous experiment shows that the performance of L7FP degrades more quickly than Envoy’s. This is to be expected, as eBPF programs are executed in a virtual machine that lacks some runtime optimizations like SIMD [47, 60]. Moreover, calls to a bpf_helper function can be expensive, hurting performance further. Thus, the more complex a policy is, the smaller the performance gain of L7FP becomes. We illustrate this by measuring the main sources of overhead: parsing the message, enforcing the policy, and IPC. Note that we only measure the overhead induced by the service proxy, and ignore the runtime of the application itself. It follows that L7FP does not exhibit any IPC overhead, as it runs in kernel space. For each data point, the load generator sends 5K req/s for three minutes4 to collect enough samples. The result is shown in Figure 10: While Envoy’s overhead grows by 206% (251% with the L4 fast path), L7FP grows by 877%. It also becomes apparent that for Envoy, only the parsing overhead grows, whereas for L7FP, the policy enforcement overhead grows at the same rate as parsing. Despite this, even for the maximum complexity 𝑐 = 1, L7FP’s
Discussion and Limitations
We start this section by discussing the future work that this project has made possible. Then we discuss the main limitations of L7FP, and outline what it takes to alleviate them. Accelerating other applications. L7FP introduces a practical way to parse and process L7 protocols in the kernel. As long as the message processing is not too complex (c.f. §5.4), L7FP can significantly improve throughput and request latency. This also opens the door to accelerate other applications, not just service proxies. For example, application-level firewalls could profit heavily from an eBPF offload and facilitate their deployment. L7FP’s core ideas also apply to web servers. It could serve simple HTTP requests directly from kernel space, or cache more complex ones. Parsing more complex protocols. The current version of L7FP supports HTTP/1.1 and HTTP/2. Future versions can extend this support, e.g. for gRPC [25], by constructing DFAs that operate on the respective encoding. In this regard, HTTP/3 presents a special case. It uses QUIC, which the latest Linux kernel does not support. This renders it incompatible with the eBPF runtime. However, in-kernel support for QUIC is on the horizon [19].
4We choose this rate because, in our setup, it exercises the full application without exceeding the maximum throughput that all configurations can process (see Figure 9)
11
Arxiv, 2026
Brandner et al.
Implementing more policies. L7FP currently supports a handful of policies that are, according to our studies, commonly used in today’s service meshes. Adding support for new policies is as simple as implementing a template. Our study has shown that 11% of L7 policies are not fully compatible with the eBPF runtime and require kernel changes. Implementing one of such policies, e.g., a customization policy in the form of a Lua script, requires the user to additionally implement a kernel module that provides the Lua runtime to L7FP’s data plane. Standard eBPF techniques can be used to call the kernel module from within the template.
automatic application offload to kernel space. The Linux kernel uses mechanisms like the kernel connection multiplexor (KCM) [36] to perform message delineation in kernel space. L7FP’s parser augments KCM to provide an HTTP-based message interface. [39] studies the potential of eBPF to read L7 payloads. They find that eBPF-based telemetry is more efficient than state-of-the-art systems, but is also limited to matching only 48 B of data. We show that recent advances in the Linux kernel have made it possible to match up to 16 kB of data. [49] is another orthogonal approach to filter packets using regexes in eBPF. L7FP employs a similar approach (Aho-Corasick DFAs) to parse messages efficiently. Copper [58] proposes a policy DSL that facilitates the management of diverse data planes and helps minimize the data plane resources. CanalMesh [65] implements a multi-tenant remote mesh gateway, eliminating the need for a sidecar proxy. This approach improves throughput and latency while simplifying orchestration and pod intrusion. Nevertheless, the deployment of a secure and error-free multi-tenant proxy is challenging. Finally, mRPC [12] and ServiceRouter [57] eliminate the service proxy completely by reintegrating policy enforcement back into the application. This yields significant performance gains, but couples the life cycle of the pod to that of the policy enforcement.
Enforcing more complex policies. L7FP’s data plane complexity is bound by the eBPF verifier. It limits the number of instructions an eBPF program may have, and fails to verify the safety of programs with too complex control flows. To address this, the eBPF community is actively working on increasing these limits [2], and academia has produced numerous works [8, 66, 67] that aim to improve the verifier’s accuracy. L7FP can also employ standard techniques like kfuncs and tail calls to circumvent this limitation. We emphasize however, that for all experiments in this paper, L7FP synthesizes a data plane that fits into a single eBPF program.
7
Specializing the kernel. There is a long line of work that aims at specializing the kernel [14, 50, 52, 53], or specifically the network stack [13]. [9] propose an automatic specialization of protocol stacks, tailored towards the current usage context. [43] employ Netmap [55] to implement a specialized zero-copy network stack operating from user space. LinuxFP [1] continuously profiles the kernel to automatically synthesize and deploy a message processing fast path.
Related Work
Optimizing L4 policies. Cilium [16] and Calico [11] are the de-facto industry standard for service meshes. They enforce L4 policies in kernel space, but remain dependent on user space service proxies to enforce L7 policies. We replicate their data path with the “L4 Fast Path” in §5.2 and find that L7FP achieves up to 3× higher throughput. Other approaches reduce IPC overheads by bypassing the network stack [6, 22, 27, 43, 55], or by batching the packets to be processed [26]. Such approaches require application modifications – L7FP remains transparent. OnCache [41] accelerates container overlay networks by caching tunnel headers in eBPF. Slim [69] is a container overlay network that implements lightweight network virtualization by manipulating connection-level metadata when connections are established. Spright [54] is a serverless framework that redirects traffic at the socket level. It uses shared memory to implement zerocopy message delivery. Deploying one sidecar per pod incurs a large overhead in the data plane due to the increased CPU utilization, but also makes the control plane more complex. Ambient [30] addresses this by deploying a per-node L4 service proxy. Finally, multiple works [10, 48, 62] offload L4 policies like packet forwarding and filtering to programmable NICs.
8
Conclusion
The service mesh simplifies the development of web applications by abstracting away the network layer. But its data plane, the service proxy, is responsible for major performance degradations, resulting in higher request latencies. We presented L7FP, a transparent kernel space fast path for service proxies. We demonstrated the need for applicationlayer processing in kernel space and showed that this has become a possibility with the latest advances in the Linux kernel. L7FP improves the performance of service meshes dramatically, lowering the request latency while sustaining more throughput. The service proxy remains agnostic of L7FP, allowing for a flexible deployment. We consider L7FP to be the first step that shows the performance benefits of application-layer processing in the kernel. This opens the door for performance optimization of many Optimizing L7 policies. [63] advocate for L7 policy endifferent applications that profit from application-level proforcement in kernel space. [3] proposes to incorporate application- cessing in the kernel. layer protocols into SDN architectures. [61] proposes an This work does not raise any ethical issues. 12
Offloading L7 Policies to the Kernel
Arxiv, 2026
References
[20] eBPF Community. 2026. eBPF. Retrieved July 27, 2025 from https: //ebpf.io [21] Envoy. 2026. Envoy. Retrieved August 1, 2025 from https://www. envoyproxy.io [22] Linux Foundation. 2015. Data Plane Development Kit (DPDK). Retrieved May 28, 2026 from http://www.dpdk.org [23] Yu Gan, Yanqi Zhang, Dailun Cheng, Ankitha Shetty, Priyal Rathi, Nayan Katarki, Ariana Bruno, Justin Hu, Brian Ritchken, Brendon Jackson, Kelvin Hu, Meghna Pancholi, Yuan He, Brett Clancy, Chris Colen, Fukang Wen, Catherine Leung, Siyuan Wang, Leon Zaruvinsky, Mateo Espinosa, Rick Lin, Zhongling Liu, Jake Padilla, and Christina Delimitrou. 2019. An Open-Source Benchmark Suite for Microservices and Their Hardware-Software Implications for Cloud & Edge Systems. In Proceedings of the Twenty-Fourth International Conference on Architectural Support for Programming Languages and Operating Systems (ASPLOS ’19). ACM, 3–18. https://doi.org/10.1145/3297858. 3304013 [24] Grafana. 2026. Grafana k6: Load testing for engineering teams. Retrieved January 22, 2026 from https://k6.io [25] gRPC Authors. 2015. gRPC. Retrieved January 20, 2026 from https: //grpc.io/ [26] Shuveb Hussain. 2020. What is io_uring? Retrieved January 22, 2026 from https://unixism.net/loti/what_is_io_uring.html [27] Toke Høiland-Jørgensen, Jesper Dangaard Brouer, Daniel Borkmann, John Fastabend, Tom Herbert, David Ahern, and David Miller. 2018. The eXpress data path: fast programmable packet processing in the operating system kernel. In Proceedings of the 14th International Conference on emerging Networking EXperiments and Technologies (CoNEXT ’18). ACM, 54–66. https://doi.org/10.1145/3281411.3281443 [28] Internet Engineering Task Force (IETF). 2015. HPACK: Header Compression for HTTP/2. Retrieved January 22, 2026 from https: //datatracker.ietf.org/doc/html/rfc7541 [29] Istio. 2026. Istio. Retrieved January 22, 2026 from https://istio.io [30] Istio. 2026. Istio Ambient. Retrieved January 22, 2026 from https: //istio.io/latest/docs/ambient/overview [31] Istio. 2026. Istio GitHub Repository. Retrieved August 1, 2025 from https://github.com/istio/istio [32] Devki Nandan Jha, Saurabh Garg, Prem Prakash Jayaraman, Rajkumar Buyya, Zheng Li, Graham Morgan, and Rajiv Ranjan. 2021. A study on the evaluation of HPC microservices in containerized environment. Concurrency and Computation: Practice and Experience 33, 7 (2021), 1–1. [33] Richard Jones. 2026. Ketama. Retrieved January 22, 2026 from https://github.com/RJ/ketama [34] Richard Jones. 2026. xxHash: Extremely fast non-cryptographic hash function. Retrieved January 22, 2026 from https://xxhash.com/doc/v0. 8.2/index.html [35] Gopal Kakivaya, Lu Xun, Richard Hasha, Shegufta Bakht Ahsan, Todd Pfleiger, Rishi Sinha, Anurag Gupta, Mihail Tarta, Mark Fussell, Vipul Modi, Mansoor Mohsin, Ray Kong, Anmol Ahuja, Oana Platon, Alex Wun, Matthew Snider, Chacko Daniel, Dan Mastrian, Yang Li, Aprameya Rao, Vaishnav Kidambi, Randy Wang, Abhishek Ram, Sumukh Shivaprakash, Rajeet Nair, Alan Warwick, Bharat S. Narasimman, Meng Lin, Jeffrey Chen, Abhay Balkrishna Mhatre, Preetha Subbarayalu, Mert Coskun, and Indranil Gupta. 2018. Service fabric: a distributed platform for building microservices in the cloud. In Proceedings of the Thirteenth EuroSys Conference (Porto, Portugal) (EuroSys ’18). Association for Computing Machinery, New York, NY, USA, Article 33, 15 pages. https://doi.org/10.1145/3190508.3190546 [36] The kernel development community. 2026. Kernel Connection Multiplexor. Retrieved January 22, 2026 from https://docs.kernel.org/ networking/kcm.html [37] The kernel development community. 2026. Kernel TLS offload. Retrieved January 22, 2026 from https://docs.kernel.org/networking/tls-
[1] Marcelo Abranches, Erika Hunhoff, Rohan Eswara, Oliver Michel, and Eric Keller. 2024. LinuxFP: Transparently accelerating linux networking. In 2024 IEEE 44th International Conference on Distributed Computing Systems (ICDCS). IEEE, 543–554. [2] Daroc Alden. 2025. Taking BPF programs beyond one-million instructions. Retrieved January 22, 2026 from https://lwn.net/Articles/ 1017116/ [3] Gianni Antichi and Gábor Rétvári. 2020. Full-stack SDN: The Next Big Challenge?. In Proceedings of the Symposium on SDN Research (SOSR ’20). ACM, 48–54. https://doi.org/10.1145/3373360.3380834 [4] auth0. 2026. JSON Web Tokens. Retrieved January 22, 2026 from https://jwt.io [5] Go Authors. 2026. Go HTTP/2 Library. Retrieved January 20, 2026 from https://pkg.go.dev/golang.org/x/net/http2/hpack#HeaderField [6] Adam Belay, George Prekas, Ana Klimovic, Samuel Grossman, Christos Kozyrakis, and Edouard Bugnion. 2014. IX: A Protected Dataplane Operating System for High Throughput and Low Latency. In 11th USENIX Symposium on Operating Systems Design and Implementation (OSDI 14). USENIX Association, Broomfield, CO, 49–65. https://www. usenix.org/conference/osdi14/technical-sessions/presentation/belay [7] Fatéma Zahra Benchara, Mohamed Youssfi, Omar Bouattane, and Hassan Ouajji. 2016. A new efficient distributed computing middleware based on cloud micro-services for HPC. In 2016 5th International Conference on Multimedia Computing and Systems (ICMCS). 354–359. https://doi.org/10.1109/ICMCS.2016.7905644 [8] Sanjit Bhat and Hovav Shacham. 2022. Formal verification of the linux kernel ebpf verifier range analysis. [9] S. Bhatia, C. Consel, A.-F. Le Meur, and C. Pu. 2004. Automatic specialization of protocol stacks in operating system kernels. In 29th Annual IEEE International Conference on Local Computer Networks. 152–159. https://doi.org/10.1109/LCN.2004.28 [10] Marco Spaziani Brunella, Giacomo Belocchi, Marco Bonola, Salvatore Pontarelli, Giuseppe Siracusano, Giuseppe Bianchi, Aniello Cammarano, Alessandro Palumbo, Luca Petrucci, and Roberto Bifulco. 2022. hXDP: Efficient software packet processing on FPGA NICs. Commun. ACM 65, 8 (July 2022), 92–100. https://doi.org/10.1145/3543668 [11] Calico. 2026. Calico. Retrieved January 22, 2026 from https://www. tigera.io/project-calico [12] Jingrong Chen, Yongji Wu, Shihan Lin, Yechen Xu, Xinhao Kong, Thomas Anderson, Matthew Lentz, Xiaowei Yang, and Danyang Zhuo. 2023. Remote Procedure Call as a Managed System Service. In 20th USENIX Symposium on Networked Systems Design and Implementation (NSDI 23). USENIX Association, Boston, MA, 141–159. https://www. usenix.org/conference/nsdi23/presentation/chen-jingrong [13] Ruining Chen and Guoao Sun. 2018. A Survey of Kernel-Bypass Techniques in Network Stack. In Proceedings of the 2018 2nd International Conference on Computer Science and Artificial Intelligence (CSAI ’18). ACM, 474–477. https://doi.org/10.1145/3297156.3297242 [14] Oliver RA Chick, Lucian Carata, James Snee, Nikilesh Balakrishnan, and Ripduman Sohan. 2016. Shadow kernels: A general mechanism for kernel specialization in existing operating systems. ACM SIGOPS Operating Systems Review 50, 1 (2016), 3–8. [15] Cilium. 2026. Cilium GitHub Repository. Retrieved August 1, 2025 from https://github.com/cilium/cilium [16] Cilium. 2026. Cilium Service Mesh. Retrieved January 22, 2026 from https://cilium.io/use-cases/service-mesh [17] Linux Community. 2026. BPF Kernel Functions (kfuncs). Retrieved January 22, 2026 from https://docs.kernel.org/bpf/kfuncs.html [18] Linux Community. 2026. Linux Kernel Crypto API. Retrieved January 22, 2026 from https://www.kernel.org/doc/html/v4.20/crypto/index. html [19] Jonathan Corbet. 2025. QUIC for the kernel. Retrieved January 22, 2026 from https://lwn.net/Articles/1029851/ 13
Arxiv, 2026
Brandner et al. Fifteenth ACM Symposium on Operating Systems Principles (Copper Mountain, Colorado, USA) (SOSP ’95). Association for Computing Machinery, New York, NY, USA, 314–321. https://doi.org/10.1145/ 224056.224080 [53] Calton Pu, Andrew P Black, Crispin Cowan, Jonathan Walpole, and Charles Consel. 1997. Microlanguages for operating system specialization. (1997). [54] Shixiong Qi, Leslie Monis, Ziteng Zeng, Ian-chin Wang, and K. K. Ramakrishnan. 2022. SPRIGHT: extracting the server from serverless computing! high-performance eBPF-based event-driven, sharedmemory processing. In Proceedings of the ACM SIGCOMM 2022 Conference (SIGCOMM ’22). ACM. https://doi.org/10.1145/3544216.3544259 [55] Luigi Rizzo, Marta Carbone, and Gaetano Catalli. 2012. Transparent acceleration of software packet forwarding using netmap. In 2012 Proceedings IEEE INFOCOM. IEEE, 2471–2479. [56] Mohammad Reza Saleh Sedghpour, Cristian Klein, and Johan Tordsson. 2022. An Empirical Study of Service Mesh Traffic Management Policies for Microservices. In Proceedings of the 2022 ACM/SPEC on International Conference on Performance Engineering (ICPE ’22). ACM, 17–27. https: //doi.org/10.1145/3489525.3511686 [57] Harshit Saokar, Soteris Demetriou, Nick Magerko, Max Kontorovich, Josh Kirstein, Margot Leibold, Dimitrios Skarlatos, Hitesh Khandelwal, and Chunqiang Tang. 2023. ServiceRouter: Hyperscale and Minimal Cost Service Mesh at Meta. In 17th USENIX Symposium on Operating Systems Design and Implementation (OSDI 23). USENIX Association, Boston, MA, 969–985. https://www.usenix.org/conference/osdi23/ presentation/saokar [58] Divyanshu Saxena, William Zhang, Shankara Pailoor, Isil Dillig, and Aditya Akella. 2025. Copper and Wire: Bridging Expressiveness and Performance for Service Mesh Policies. In Proceedings of the 30th ACM International Conference on Architectural Support for Programming Languages and Operating Systems, Volume 1 (ASPLOS ’25). ACM, 233–248. https://doi.org/10.1145/3669940.3707257 [59] Korakit Seemakhupt, Brent E Stephens, Samira Khan, Sihang Liu, Hassan Wassel, Soheil Hassas Yeganeh, Alex C Snoeren, Arvind Krishnamurthy, David E Culler, and Henry M Levy. 2023. A cloud-scale characterization of remote procedure calls. In Proceedings of the 29th Symposium on Operating Systems Principles. 498–514. [60] Farbod Shahinfar, Sebastiano Miano, Aurojit Panda, and Gianni Antichi. 2025. Demystifying Performance of eBPF Network Applications. Proc. ACM Netw. 3, CoNEXT3, Article 16 (Sept. 2025), 21 pages. https://doi.org/10.1145/3749216 [61] Farbod Shahinfar, Sebastiano Miano, Giuseppe Siracusano, Roberto Bifulco, Aurojit Panda, and Gianni Antichi. 2023. Automatic Kernel Offload Using BPF. In Proceedings of the 19th Workshop on Hot Topics in Operating Systems (HOTOS ’23). ACM, 143–149. https://doi.org/10. 1145/3593856.3595888 [62] Rajath Shashidhara, Tim Stamler, Antoine Kaufmann, and Simon Peter. 2022. FlexTOE: Flexible TCP Offload with Fine-Grained Parallelism. In 19th USENIX Symposium on Networked Systems Design and Implementation (NSDI 22). USENIX Association, Renton, WA, 87–102. https: //www.usenix.org/conference/nsdi22/presentation/shashidhara [63] Giulio Sidoretti, Sebastiano Miano, Stefano Salsano, Gianni Antichi, and Aurojit Panda. 2023. Application Layer Processing Offload in the Kernel. [64] Mark Slee, Aditya Agarwal, and Marc Kwiatkowski. 2007. Thrift: Scalable cross-language services implementation. Facebook white paper 5, 8 (2007), 127. [65] Enge Song, Yang Song, Chengyun Lu, Tian Pan, Shaokai Zhang, Jianyuan Lu, Jiangu Zhao, Xining Wang, Xiaomin Wu, Minglan Gao, Zongquan Li, Ziyang Fang, Biao Lyu, Pengyu Zhang, Rong Wen, Li Yi, Zhigang Zong, and Shunmin Zhu. 2024. Canal Mesh: A Cloud-Scale Sidecar-Free Multi-Tenant Service Mesh Architecture. In Proceedings of the ACM SIGCOMM 2024 Conference (ACM SIGCOMM ’24). ACM,
offload.html [38] The kernel development community. 2026. Stream Parser (strparser). Retrieved May 28, 2026 from https://docs.kernel.org/networking/ strparser.html [39] Ashwin Kumar, Abhik Bose, Khushboo Tiwari, Arnav Mishra, Abhishek Dixit, Abuhujair Khan, and Mythili Vutukuru. 2024. Feasibility of Application Layer Header Parsing in eBPF and P4. In 2024 IFIP Networking Conference (IFIP Networking). 475–481. https: //doi.org/10.23919/IFIPNetworking62109.2024.10619855 [40] Wubin Li, Yves Lemieux, Jing Gao, Zhuofeng Zhao, and Yanbo Han. 2019. Service Mesh: Challenges, State of the Art, and Future Research Opportunities. In 2019 IEEE International Conference on ServiceOriented System Engineering (SOSE). IEEE, 122–1225. https://doi.org/ 10.1109/sose.2019.00026 [41] Shengkai Lin, Shizhen Zhao, Peirui Cao, Xinchi Han, Quan Tian, Wenfeng Liu, Qi Wu, Donghai Han, and Xinbing Wang. 2023. ONCache: A Cache-Based Low-Overhead Container Overlay Network. https://doi.org/10.48550/ARXIV.2305.05455 [42] Linkerd. 2026. Linkerd. Retrieved January 22, 2026 from https: //linkerd.io [43] Ilias Marinos, Robert N.M. Watson, and Mark Handley. 2014. Network stack specialization for performance. ACM SIGCOMM Computer Communication Review 44, 4 (August 2014), 175–186. https: //doi.org/10.1145/2740070.2626311 [44] Sean McArthur. 2026. Rust HTTP Library. Retrieved January 20, 2026 from https://docs.rs/http/latest/http/header/struct.HeaderValue.html# method.set_sensitive [45] Nick McKeown, Tom Anderson, Hari Balakrishnan, Guru Parulkar, Larry Peterson, Jennifer Rexford, Scott Shenker, and Jonathan Turner. 2008. OpenFlow: enabling innovation in campus networks. ACM SIGCOMM Computer Communication Review 38, 2 (March 2008), 69–74. https://doi.org/10.1145/1355734.1355746 [46] Dylan McNamee, Jonathan Walpole, Calton Pu, Crispin Cowan, Charles Krasic, Ashvin Goel, Perry Wagle, Charles Consel, Gilles Muller, and Renauld Marlet. 2001. Specialization tools and techniques for systematic optimization of system software. ACM Transactions on Computer Systems (TOCS) 19, 2 (2001), 217–251. [47] Sebastiano Miano, Xiaoqi Chen, Ran Ben Basat, and Gianni Antichi. 2023. Fast In-kernel Traffic Sketching in eBPF. ACM SIGCOMM Computer Communication Review 53, 1 (January 2023), 3–13. https://doi.org/10.1145/3594255.3594256 [48] YoungGyoun Moon, SeungEon Lee, Muhammad Asim Jamshed, and KyoungSoo Park. 2020. AccelTCP: Accelerating Network Applications with Stateful TCP Offloading. In 17th USENIX Symposium on Networked Systems Design and Implementation (NSDI 20). USENIX Association, Santa Clara, CA, 77–92. https://www.usenix.org/conference/nsdi20/ presentation/moon [49] Justin Ngai. 2025. Kernel-Resident Regex and Jails: DFA-powered eBPF filtering and certificate-safe agent isolation at fleet scale. Retrieved January 20, 2026 from https://lpc.events/event/19/contributions/2176 [50] Somu Perianayagam, HaiFeng He, Mohan Rajagopalan, Gregory Andrews, and Saumya Debray. 2006. Profile-guided specialization of an operating system kernel. In Proc. Workshop on Binary Instrumentation and Applications. [51] Ben Pfaff, Justin Pettit, Teemu Koponen, Ethan Jackson, Andy Zhou, Jarno Rajahalme, Jesse Gross, Alex Wang, Joe Stringer, Pravin Shelar, Keith Amidon, and Martin Casado. 2015. The Design and Implementation of Open vSwitch. In 12th USENIX Symposium on Networked Systems Design and Implementation (NSDI 15). USENIX Association, Oakland, CA, 117–130. https://www.usenix.org/conference/nsdi15/ technical-sessions/presentation/pfaff [52] C. Pu, T. Autrey, A. Black, C. Consel, C. Cowan, J. Inouye, L. Kethana, J. Walpole, and K. Zhang. 1995. Optimistic incremental specialization: streamlining a commercial operating system. In Proceedings of the 14
Offloading L7 Policies to the Kernel
Arxiv, 2026
860–875. https://doi.org/10.1145/3651890.3672221 [66] Hao Sun and Zhendong Su. 2024. Validating the eBPF Verifier via State Embedding. In 18th USENIX Symposium on Operating Systems Design and Implementation (OSDI 24). USENIX Association, Santa Clara, CA, 615–628. https://www.usenix.org/conference/osdi24/presentation/ sun-hao [67] Harishankar Vishwanathan, Matan Shachnai, Srinivas Narayana, and Santosh Nagarakatte. 2023. Verifying the Verifier: eBPF Range Analysis Verification. Springer Nature Switzerland, 226–251. https://doi.org/ 10.1007/978-3-031-37709-9_12 [68] Xiangfeng Zhu, Guozhen She, Bowen Xue, Yu Zhang, Yongsu Zhang, Xuan Kelvin Zou, Xiongchun Duan, Peng He, Arvind Krishnamurthy, Matthew Lentz, Danyang Zhuo, and Ratul Mahajan. 2022. Dissecting Service Mesh Overheads. https://doi.org/10.48550/ARXIV.2207.00592 [69] Danyang Zhuo, Kaiyuan Zhang, Yibo Zhu, Hongqiang Harry Liu, Matthew Rockett, Arvind Krishnamurthy, and Thomas Anderson. 2019. Slim: OS Kernel Support for a Low-Overhead Container Overlay Network. In 16th USENIX Symposium on Networked Systems Design and Implementation (NSDI 19). USENIX Association, Boston, MA, 331–344. https://www.usenix.org/conference/nsdi19/presentation/zhuo
15