Hi HN, Shivansh (founder) here, happy to answer any questions folks might have about the implementation and the benchmarks!
An eBPF loophole: Using XDP for egress traffic
61–70 of 81 posts
Re: An eBPF loophole: Using XDP for egress traffic
#62We use it quite a ton for capturing and dashboarding inbound network traffic over at https://yeet.cx
I am really excited for the future of eBPF especially with tcx now being available in Debian 13. The tc API was very hard to work with.
Re: An eBPF loophole: Using XDP for egress traffic
#63Hi HN, Shivansh (founder) here, happy to answer any questions folks might have about the implementation and the benchmarks!
The "Architect" live migration tech seems super cool and useful on its own. Is it available independent of your kubernetes stuff?
Re: An eBPF loophole: Using XDP for egress traffic
#64Earlier quoted context omitted.
No this was multiple connections - and we tried with both `iperf2` and `iperf3`, UDP and TCP traffic. UDP actually does much worse on `iptables` than TCP, and I'm not sure why just yet.
For UDP I'd look into GSO/GRO to get an upper bound on what pure kernel can do. With performance benchmarking, specially in networking there is no end to "oh, but did you think of that?!" :)
`iperf3 -c 172.31.45.187 -p 5201 -P 128 -t 5 -b 512M -u -l 1448 --bidir | grep "\[SUM\]\[\(TX\|RX\)-C\].*receiver"`
We're also looking at using packet generators to test raw packet throughput. There's a lot more bottlenecks we can cleanup I'm sure.
Re: An eBPF loophole: Using XDP for egress traffic
#65The page has no text for me (only the table of contents on the side, that updates by scrolling over the completely blank purple page …) I'm using Firefox
Removing this: @layer base { :root, #nd-docs-layout { --fd-layout-offset: max(calc(50vw - var(--fd-layout-width)/2),0px); } } fixes it for me and I can read the text now … EDIT: Oh, or making the window less than around 3000 px wide does also fix it, and resizing you can see what is happening there …
Re: An eBPF loophole: Using XDP for egress traffic
#66Hey I can’t browse the link crashes on ios
Re: An eBPF loophole: Using XDP for egress traffic
#67Earlier quoted context omitted.
We absolutely ran into these issues. A couple notes that help quite a bit: 1. Always build the eBPF programs in a container - this is great for reproducibility of course, but also makes DevX on MacOS better for those who prefer to use that. 2. You actually can do a full checksum! You need to limit the MTU but you can: static __always_inline void tcp_checksum(const struct iphdr *ip_header, struct tcphdr *tcp_header, c…
How do containers help when bpf is mostly a matter of kernel version?
Re: An eBPF loophole: Using XDP for egress traffic
#68Re: An eBPF loophole: Using XDP for egress traffic
#69Earlier quoted context omitted.
This is why I am always skeptical when anyone writes that they are the first to do something… the added caveat is always, “that we know of”
"Who did it first" is not interesting to me, but what they're doing isn't a "loophole"; that's all I'm concerned with.
Re: An eBPF loophole: Using XDP for egress traffic
#70Earlier quoted context omitted.
How do containers help when bpf is mostly a matter of kernel version?
they don't its just the poster wanting people to do what they prefer
“Checksum code does not work for LLVM-14, but it works for LLVM-13”
Newer compilers might use new optimizations that the verifier won’t be happy with. I guess the other option would be to find some config option to disable that specific incompatible optimization.