EInsn: eBPF Instruction Extension Library

• EInsn is a concrete eBPF instruction-extension library that replaces multi-instruction idioms with efficient native operations using dual-form semantics.
• It provides seven targeted operations—including rotate, conditional select, and byte swap—resulting in up to 24% speedup in microbenchmarks on x86-64 and ARM64.
• EInsn maintains verifier safety by using proof sequences alongside native emits, reducing code size and mitigating limitations of the standard eBPF JIT.

EInsn is a concrete instruction-extension library for eBPF introduced within Kops, a mechanism for extending the eBPF compilation pipeline with native operations while preserving the existing verifier-centric safety path. Its design target is a narrow but consequential class of hardware idioms that the stock kernel JIT compiles poorly because the JIT translates one eBPF instruction at a time in a single pass. In EInsn, each operation has a verifier-visible proof sequence in ordinary eBPF and a JIT-visible native emit in machine instructions, so the same program can verify as vanilla eBPF yet execute as shorter native code (Zheng et al., 23 Jun 2026). The library comprises seven operations—rotate, conditional select, bit extract, byte swap, prefetch, bulk copy, and LEA—and is evaluated on x86-64 and ARM64, where it yields up to 24% speedup on microbenchmarks and up to 12% on production applications (Zheng et al., 23 Jun 2026).

1. Definition and problem setting

EInsn addresses a specific source of inefficiency in the standard eBPF pipeline. In that pipeline, userspace compilers optimize before lowering into the fixed eBPF ISA, the verifier checks safety properties over defined eBPF opcodes, and the kernel JIT translates verified bytecode to native code one eBPF instruction at a time. The kernel keeps the JIT simple for trustworthiness and maintainability, but that design misses multi-instruction idioms such as rotate, bit extract, conditional select, and fused endian load (Zheng et al., 23 Jun 2026).

The empirical characterization motivating EInsn is explicit. The same code can run about $1.57\times$ slower on x86-64 and $1.98\times$ slower on ARM64 through the standard eBPF pipeline than under direct native compilation, while an optimizing compiler given the same verified bytecode recovers 93–94% of that gap (Zheng et al., 23 Jun 2026). This isolates the bottleneck to the ISA boundary and the kernel JIT’s single-pass, per-opcode translation strategy rather than to the verifier as such.

Within Kops, EInsn occupies the “hardware-idiom” point in the design space. It does not attempt whole-program native replacement, general register allocation, instruction scheduling, or broad in-kernel optimization. Instead, it targets a bounded set of local patterns for which native hardware has compact support but eBPF has only decomposed encodings (Zheng et al., 23 Jun 2026). A plausible implication is that EInsn is best understood not as a new ISA in the conventional sense, but as an extension surface for verified idiom substitution.

2. Kops integration and dual-form semantics

Kops provides the general mechanism; EInsn is its first concrete instantiation for hardware idioms. The core design is dual-form operations: each operation has a proof sequence of vanilla eBPF instructions and a native emit of machine instructions. The verifier checks only the proof sequence, while the JIT uses the native emit at runtime (Zheng et al., 23 Jun 2026).

This arrangement is central to the TCB argument. Because the verifier checks the proof sequence, Kops does not need to teach the verifier the semantics of each new operation. The paper states that “the native emit is the only per-operation addition to the TCB” (Zheng et al., 23 Jun 2026). In contrast, directly extending the kernel JIT would place more optimization logic and architecture-specific code in the kernel core.

Operationally, the pipeline is staged. A userspace recognizer matches idiom patterns before load and rewrites them into extended instructions encoded as a call+sidecar pair. Before verification, Kops lowers each extended instruction back into its proof sequence and runs the unmodified verifier on the lowered program. After successful verification, Kops restores the extended instructions so that the JIT can dispatch to the registered native emit; if no architecture-specific emit exists, the site is rewritten back to the proof sequence before JIT (Zheng et al., 23 Jun 2026).

The encoding itself is deliberately conservative. No new eBPF opcode is introduced. An extended instruction is represented as a BPF_CALL followed by a MOV64_K sidecar with a reserved src_reg value marking the pair as Kops-specific. The call carries the BTF ID of the operation’s stub kfunc and an index into fd_array for the module’s BTF file descriptor; the sidecar carries a 52-bit payload with destination-register or form-tag information, an auxiliary field, and an immediate or configuration field (Zheng et al., 23 Jun 2026).

3. Operation set and native idioms

EInsn contains seven operations, each chosen because native hardware offers a compact idiom that the stock eBPF lowering path cannot reconstruct effectively.

Operation	Proof sequence	Native emit
Rotate	two shifts + or	ROL / ROR
Conditional select	branch + move	CMP+CMOV / TST+CSEL
Bit extract	shift + and	BEXTR / UBFX
Byte swap	load + byte swap	MOVBE / LDR+REV
Prefetch	no-op (JA +0)	PREFETCHT0 / PRFM
Bulk copy	loads + stores	MOV / LDP+STP
LEA	shift + adds	LEA / --

Rotate is the motivating example. A 64-bit variable rotate compiles to one instruction under direct native compilation, eight instructions in eBPF, and 15 x86-64 machine instructions under the stock kernel JIT; EInsn can instead emit a single native rotate instruction (Zheng et al., 23 Jun 2026). Conditional select is smaller in absolute savings—native 2 instructions, eBPF 3, stock JIT 4—but still meaningful, especially because it replaces branch+move with branchless native support. On ARM64, its realization is split into two extended instructions, one emitting TST and one emitting CSEL, whereas x86-64 uses one extended instruction for CMP+CMOV (Zheng et al., 23 Jun 2026).

Bit extract captures shift-and-mask idioms via BEXTR on x86-64 and UBFX on ARM64. Byte swap captures endian conversion fused with load; its native emit is MOVBE on x86-64 and LDR+REV on ARM64. Bulk copy replaces repeated loads and stores with a more compact memory-copy idiom; for the 64-byte example reported in the paper, native code uses 4 instructions, eBPF uses 16, and the stock JIT also uses 16 (Zheng et al., 23 Jun 2026).

Prefetch is a special case because eBPF has no semantic equivalent for prefetch. The recognizer inserts it at selected sites, and the proof sequence is a no-op JA +0; architecturally, prefetch is modeled as a no-op, with microarchitectural cache effects placed outside the semantic model (Zheng et al., 23 Jun 2026). LEA covers effective-address arithmetic such as shift-plus-add combinations and is available only on x86-64; ARM64 falls back to the proof sequence because no native emit is provided (Zheng et al., 23 Jun 2026).

4. Formal semantics, proof obligations, and safety model

The formal claim underlying EInsn is observational equivalence between native emit and proof sequence at the eBPF-visible architectural level. The paper states that Lean 4 proofs establish, for each supported EInsn operation, that “the eBPF expansion and the corresponding native sequence produce the same eBPF-observable architectural state” (Zheng et al., 23 Jun 2026).

The semantics framework is described as small-step register-transfer semantics for each ISA, with a program denoting the fold of its per-instruction transitions. The proof is factored through an intermediate hardware-independent specification rather than via direct x86-to-ARM equivalence. Native instruction semantics are ported from an existing formalization, and for each EInsn operation there are ISA-local correctness lemmas showing that both the proof sequence and the native sequence refine the same specification (Zheng et al., 23 Jun 2026).

The proof obligations depend on operation class. For register-only operations such as rotate, conditional select, bit extract, and LEA, correctness reduces to equality on the destination register. For memory-touching operations such as byte swap fused with its load and bulk copy, the obligation is equality on the projected architectural state over live registers and accessed memory, while leaving all other eBPF-visible memory unchanged. Prefetch is modeled as an architectural no-op, so its proof obligation is equivalence to the no-op proof sequence (Zheng et al., 23 Jun 2026).

The refinement theorem is conditional: it is stated for verifier-accepted proof sequences and verifier-safe initial states. The Lean proofs are offline development-time evidence rather than load-time checks. At runtime, the trusted path consists of the existing verifier, the existing JIT, and Kops’s generic machinery for lowering, restoration, region validation, and dispatch (Zheng et al., 23 Jun 2026). This suggests that EInsn’s safety argument is deliberately layered: verifier acceptance establishes safety of the lowered program, while proof-region constraints and offline equivalence proofs justify replacing proof regions with native emits.

5. Implementation path and proof-region constraints

EInsn operations are introduced through a combination of userspace recognizer support and loadable kernel modules. A new operation needs only descriptors in a kernel module and a pattern in the recognizer. Kops reuses BTF metadata and kfunc registration infrastructure; each module exports a stub kfunc as a BTF anchor, lists its struct bpf_einsn descriptors in a parallel array, and registers those descriptors for lookup by the verifier and JIT (Zheng et al., 23 Jun 2026).

There are two recognizer paths. One is an LLVM backend selector that matches idioms during instruction selection and emits call+sidecar directly instead of decomposed bytecode. The other is a bytecode recovery pass that re-matches idioms on already-compiled eBPF bytecode, including bytecode produced by another toolchain or patterns missed by the selector. The recovery pass checks rewrite-side semantic conditions such as whether a temporary register overwritten by a replacement is dead afterward, but even incorrect matching does not compromise verifier-enforced safety because the lowered program is rechecked (Zheng et al., 23 Jun 2026).

Kops constrains proof regions so that restoring extended instructions after verification is sound. Each proof region must be single-entry and single-exit, contain no nested extended instructions, contain no calls, exits, or backward jumps, and have no jumps entering or leaving except at region boundaries (Zheng et al., 23 Jun 2026). These constraints make the proof region behave like a single instruction from the verifier’s perspective.

EInsn requires JIT support. There is no interpreter support, and a kernel without JIT rejects programs containing extended instructions (Zheng et al., 23 Jun 2026). This sharply delimits the deployment model: EInsn is a JIT-mediated optimization interface rather than a portable extension across all eBPF execution modes.

6. Performance characteristics and policy sensitivity

The evaluation separates EInsn from Kops’s more aggressive whole-program native-replacement mode. For EInsn itself, the reported microbenchmark geomean speedup over the stock kernel eBPF JIT is $1.242\times$ on x86-64, corresponding to a 19.47% execution-time reduction, and $1.222\times$ on ARM64, corresponding to an 18.17% reduction (Zheng et al., 23 Jun 2026). The abstract summarizes the peak microbenchmark gains as up to 24% on x86-64 and up to 22% on ARM64.

Code size also shrinks: to $0.772\times$ baseline on x86-64, a 22.8% reduction, and to $0.879\times$ on ARM64, a 12.1% reduction. On x86-64 microbenchmarks, the $1.242\times$ EInsn speedup recovers 42% of the characterized $1.57\times$ eBPF-native gap. The paper reports zero correctness mismatches on both architectures (Zheng et al., 23 Jun 2026).

Production packet-processing evaluations are more modest but still positive. On x86-64, Cilium throughput improves by $1.074\times$ with 4086 applied EInsn sites; of those, 2346 are LEA, 385 are conditional select, 766 are endian fusion, 2 are extract, and 587 are bulk memory. On ARM64, Katran throughput improves by $1.073\times$ with 21 applied sites (Zheng et al., 23 Jun 2026). The abstract’s “up to 12%” application-level speedup reflects the best result under policy variation.

Profitability is not monotone in coverage. For Cilium, the full EInsn policy applies 4086 sites and yields throughput $1.98\times$0, whereas disabling only bulk_memory reduces applied sites to 3512 but improves throughput to $1.98\times$1 and raises the BPF-cost ratio to $1.98\times$2. For Katran, a conservative ARM64 policy applies 21 sites and yields throughput $1.98\times$3, while a coverage-max policy applies 62 sites yet drops throughput to $1.98\times$4 and raises BPF cost to $1.98\times$5 (Zheng et al., 23 Jun 2026). This directly contradicts any simple assumption that more matches are necessarily better.

Load-time overhead is limited. Kernel-side load time, including verification and JIT, is reported as a 0.99× geomean ratio relative to stock over 62 microbenchmarks on x86-64, indicating no measurable overhead. End-to-end compile time including the userspace recognizer increases by 1.4–2.4× for programs with EInsn sites, but remains sub-millisecond in absolute terms (Zheng et al., 23 Jun 2026).

7. Scope, misconceptions, and terminological ambiguity

A common misconception would be to treat EInsn as a general solution to the eBPF-native performance gap. The paper is explicit that EInsn does not handle cross-instruction optimizations such as register allocation and instruction scheduling, nor does it eliminate costs associated with helpers, maps, tail calls, or other residual constraints imposed by the eBPF bytecode form (Zheng et al., 23 Jun 2026). Its contribution is a bounded optimization surface for local hardware idioms, not a full optimizing compiler in the kernel.

A second misconception would be to conflate EInsn with Kops’s whole-program native-replacement mode. The latter uses Kops to verify ordinary eBPF proof sequences while executing separately compiled native binaries as the emit, and reaches $1.98\times$6 throughput on Cilium over stock eBPF, but at the cost of a much larger TCB because the native application code is trusted rather than equivalence-proved (Zheng et al., 23 Jun 2026). EInsn is the small-TCB, idiom-level mode; the two mechanisms occupy different points in the design space.

There is also a terminological ambiguity in the literature. The phrase “Intelligent Sensor Network Routing Protocol” appears in the title of “Energy Efficient Sleep Awake Aware (EESAA) Intelligent Sensor Network Routing Protocol” (Shah et al., 2012). That paper is about a homogeneous wireless sensor network routing protocol using pair-based sleep/awake duty cycling and residual-energy-aware cluster-head selection, and it does not define any acronym exactly matching “EInsn” (Shah et al., 2012). This makes it relevant only as a potential source of acronym confusion, not as the origin of the eBPF term.

In the eBPF context, EInsn is therefore most precisely understood as Kops’s concrete seven-operation instruction-extension library. Its technical significance lies in combining verifier-checked proof sequences, architecture-specific native emits, and offline equivalence proofs to recover part of the performance lost at the eBPF ISA boundary without expanding the kernel verifier’s semantic surface (Zheng et al., 23 Jun 2026).