Repository navigation
[Architecture]: Introducing eBPF #82
Copy link
Copy link
Labels
ebpfeBPF related taskseBPF related tasksenhancementNew feature or requestNew feature or requesthelp wantedExtra attention is neededExtra attention is neededrustPull requests that update Rust codePull requests that update Rust code
Milestone
Description
Activity
- addedrustPull requests that update Rust codePull requests that update Rust codeebpfeBPF related taskseBPF related taskshelp wantedExtra attention is neededExtra attention is needed
on Mar 26, 2025 - added 5 commits that reference this issue
on Apr 8, 2025 8 remaining items
- added a sub-issue
on May 11, 2025 - added 6 commits that reference this issue
on May 14, 2025
Metadata
Metadata
Assignees
Labels
ebpfeBPF related taskseBPF related tasksenhancementNew feature or requestNew feature or requesthelp wantedExtra attention is neededExtra attention is neededrustPull requests that update Rust codePull requests that update Rust code
Type
Projects
- StatusShow more project fieldsNot Planned
Is your feature request related to a problem?
Problem Description
Sidecar proxies introduce significant overhead by adding extra complexity to the networking layer. If service A wants to communicate with service B, the message must pass through two sidecar proxies, like in the example below:
A --> Proxy A --> Proxy B --> B
Solution
By leveraging eBPF (Extended Berkeley Packet Filter), we can implement the networking layer directly at the kernel level, bypassing the user space and reducing the overhead introduced by sidecar proxies.
Additional Info
Demonstration of the communication: