Live data from Hacker News

An eBPF loophole: Using XDP for egress traffic

loopholelabs.io

61–70 of 81 posts

Re: An eBPF loophole: Using XDP for egress traffic

#61

Hi 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

#63
post #61

Hi 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?

It is! We demo'd it on stage at KubeCon last hear: https://loophole.sh/kc2024

Re: An eBPF loophole: Using XDP for egress traffic

#64

Earlier 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?!" :)

That's a great point. This was one of my iPerf3 runs at one point:

`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

#65

The 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 …

Sorry about that, we've fixed it!

Re: An eBPF loophole: Using XDP for egress traffic

#67

Earlier 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?

they don't its just the poster wanting people to do what they prefer

Re: An eBPF loophole: Using XDP for egress traffic

#69
post #60

Earlier 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.

I am guessing the `loophole` wording is just referencing their company name.

Re: An eBPF loophole: Using XDP for egress traffic

#70

Earlier 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

I figure it’s one way to keep your compiler version unchanged for eBPF work, while you might update/upgrade your dev OS packages over time for other reasons. The title of the linked issue is this:

“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.

Post reply on HN