devloperdevesh / devloperdevesh/FaultPlane

[Feat/Infra]: Implement eBPF sockmap TCP Stream Splicing for Zero-Copy Kernel-Space Cross-Worker Redirection

Open
#34 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

enhancement
Dominant language
Go
Stars
2
Forks
1
Avg merge
14m
Merged PRs (30d)
57

Description

Problem

When an upstream agent worker or automated inference cluster node encounters an infrastructure degradation, hardware fault, or 504 gateway timeout signature, traditional user-space reverse proxies handle connection interception and failure routing reactively. This requires reading the network packet byte streams out of the client socket descriptor, buffering them into user-space application memory chunks, and writing them down to a secondary fallback socket descriptor.

At extreme multi-gigabit line-rate traffic speeds (5,000+ connections/sec), this continuous user-to-kernel data-plane round-trip context switching introduces severe CPU instruction stalls, system memory bus locks, and noticeable garbage collection allocation spikes, running up tail latency variance and preventing sub-2ms failure masking.


Proposed Solution

Refactor the network ingress gateway connection routing engine inside internal/gateway/ to leverage Linux Kernel eBPF BPF_MAP_TYPE_SOCKMAP arrays and bpf_msg_redirect_hash helper primitives.

  • Initialize and configure an accelerated kernel-level lookup map layout that natively links the ingress client TCP connection streams directly to healthy available downstream worker destinations inside the kernel socket memory tier.
  • Implement an upstream failure signature parsing routine that instantly updates map indicators via the control plane when a degradation boundary is crossed.
  • Upon failover execution, the eBPF layer dynamically splices the network traffic streams from the degraded client socket straight to the target worker destination buffer natively inside the kernel space, completely bypassing user-space runtime reading loops and executing socket hot-swapping under < 500 microseconds.

Alternatives

  • Standard user-space asynchronous connection pooling driven via Go channels and mutex allocations, which provides robust execution isolation but remains fundamentally bounded by kernel-to-user memory copy performance overhead.
  • Deploying heavy traditional Layer 7 service mesh proxies (such as standard Envoy or Istio sidecar filters), which introduce noticed integration friction, heavy configuration abstractions, and notice CPU scheduling overhead during scaling surges.

Use Case

Creates an undisputed technical performance boundary for high-throughput distributed agent pipelines, enabling fault-tolerant, line-rate failure recovery and connection hot-swapping natively inside the operating system layer without dropping a single active network connection frame or leaking context state data.


Additional Notes

This configuration must maintain complete structural alignment and compliance layers with the lock-free circular buffers and cache-line padding dimensions established under issue #6 and internal storage layout parameters definitions.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by inspecting internal/gateway/ and the lock-free circular-buffer and cache-line-padding definitions from issue #6. Determine how the existing ingress routing and failure handling work before evaluating the proposed Linux eBPF sockmap approach. Done would require an agreed design, implementation, and validation of the stated failover and latency goals, but this issue names no tests or concrete entry point.

Written by the indexing model from the issue text.

Assessment

Tech stack
go, linux
Domain
infrastructure, networking, operating-systems
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Quiet
Clarity
Needs clarification
Newbie friendliness
25/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.