emmericp

8 ms·

31.
by emmericp 7y ago
Yeah, enabling noalias optimizations is on our todo-list. I think that’s one of the most interesting performance features of Rust. It could be the thing that makes Rust faster than C, ultimately. Too bad it‘s so broken in LLVM :(
32.
by emmericp 7y ago
Would need a somewhat realistic emulation of the NIC setting/clearing these flags. Also, the by far slowest steps are the MMIO access because it involves a full PCIe round trip which is hard to emulate. It will behave different at the
33.
by emmericp 7y ago
Geometric mean over their "fastest measurement at the largest workload" data set actually shows that Rust is faster than C in this benchmark
34.
by emmericp 7y ago
Another thing to point out: our 6% - 11% difference is already quite low. Netbricks [1] has a similar comparison between a Rust and a C network function (only the NF, driver in C in both cases) and they find 14% (LPM) to 20% (synthetic NF)
35.
by emmericp 7y ago
Thank you for your thoughtful comment, recommended reading: https://news.ycombinator.com/newsguidelines.html (edit: thanks for editing your comment, we can have a civil discussion here) To answer your question: Yes, that pa
36.
by emmericp 7y ago
Our results probably only hold true for workloads with a low IPC. The test case is also a very limited forwarder, but real network functions also have a relatively low IPC in my experience (don't have any numbers to back up this claim,
37.
by emmericp 7y ago
Really no point to running it without real hardware, it will perform completely differently if you don't have the MMIO accesses and DMA by the NIC in there. We'll have a VirtIO driver soon, but that's bottlenecked by the hype
38.
by emmericp 7y ago
No, we don't run with overflow checks by default; the overflow check performance analysis is a separate test.
39.
The Case for Writing Network Drivers in High-Level Programming Languages [pdf](net.in.tum.de)
6 points by emmericp 7y ago|0 comments
40.
by emmericp 8y ago
Yeah, this paper is amazing; anyone considering using the IOMMU or interested in performance at the PCIe level should read it. We can also confirm their result about the IOMMU TLB size of only 64 on the CPUs we have here. (Yes, the TLB size
41.
by emmericp 8y ago
Kernel developer says use kernel drivers instead of user space drivers, news at 11
42.
by emmericp 8y ago
This isn't about performance of user space drivers but about safer/better drivers. Whether that driver offers an XDP interface or something else is irrelevant. Also, your kernel driver running XDP should also use the IOMMU for bot
43.
by emmericp 8y ago
XDP is completely orthogonal to this work and would not have been a useful performance comparison. "Using AF_XDP" vs. "using a user space driver with IOMMU" is just apples vs. oranges. The goal we are trying to achieve i
44.
Using the IOMMU for Safe and Secure User Space Drivers [pdf](net.in.tum.de)
65 points by emmericp 8y ago|16 comments
45.
by emmericp 8y ago
Yeah, that's out of scope.
46.
by emmericp 8y ago
The test machine has 20 cores (+ hyper-threading) and we dedicated the first 4 to the NIC driver.
47.
by emmericp 8y ago
Code is on GitHub: https://github.com/pudelkoM/MoonWire It's not designed for any kind of production use and we have no plans to develop this further. It's only a quick and dirty example implementation of sev
48.
by emmericp 8y ago
Probably similar to OpenVPN as the performance-critical parts are similar.
49.
by emmericp 8y ago
Per-packet overhead dominates over per-byte overhead. This is true for almost all network functions, even if they perform heavy calculation on the payload like encryption. So large packets will always be better for your network.
50.
by emmericp 8y ago
Advisor of this thesis here; happy to answer questions
51.
by emmericp 8y ago
Previous discussion: https://news.ycombinator.com/item?id=16014307 Code: https://github.com/emmericp/ixy Cool stuff for the C that we are currently working on: https://github.com/emmeri
52.
by emmericp 8y ago
Yeah, I'd love to port a Go TCP stack like https://github.com/google/netstack to use our driver to build a microkernel-style service offering network connectivity. Running taps ( https://datatracker.ietf
53.
by emmericp 8y ago
Previous discussions about our Rust and Go drivers: https://news.ycombinator.com/item?id=18405515 https://news.ycombinator.com/item?id=18399389
54.
by emmericp 8y ago
Would look the same as rust; I haven't run the full measurement with all the packets. But sampling 1k packets/second yields the same result for C and Rust. You can't really get a faster speed than Rust here; the only minor th
55.
by emmericp 8y ago
I've added them to the git repo: https://github.com/ixy-languages/ixy-languages/blob/master/s...
56.
by emmericp 8y ago
Code on GitHub: https://github.com/ixy-languages/ixy-languages/ Discussion about the C version on GitHub in 2017: https://news.ycombinator.com/item?id=16014307
57.
by emmericp 8y ago
Check out my talk last year, that should answer that: https://media.ccc.de/v/34c3-9159-demystifying_network_cards
58.
by emmericp 8y ago
100G line rate with large packets is only 8 Mpps, that's only ~5G with 64 byte packets.
59.
by emmericp 8y ago
Yeah, 10G just isn't that much nowadays. And bigger NICs have more features in the VFs. I've just built a quick test setup: * two directly connected servers * 6 core 2.4 GHz CPU * XL710 40G NICs * My packet generator MoonGen: htt
60.
by emmericp 8y ago
Cool use of SR-IOV, I like it. We've done a few (academic) experiments with SR-IOV for flow bifurcation and we've wondered why no one seems to use it like this. The performance was quite good: neglible performance difference betwe

More ›