<story><title>Capturing Millions of Packets per Second in Linux without Third-Party Libraries</title><url>http://kukuruku.co/hub/nix/capturing-packets-in-linux-at-a-speed-of-millions-of-packets-per-second-without-using-third-party-libraries</url></story><parent_chain><item><author>revelation</author><text>This must be the 10th blog post to land on HN on the same topic, and they all walk through the same steps and all use the same hardware (ixgbe), which is by the way a hard prerequisite to make much of these strategies effective.&lt;p&gt;In any case, stop reinventing the wheel, just use a library purpose-made:&lt;p&gt;&lt;a href=&quot;http:&amp;#x2F;&amp;#x2F;dpdk.org&amp;#x2F;&quot; rel=&quot;nofollow&quot;&gt;http:&amp;#x2F;&amp;#x2F;dpdk.org&amp;#x2F;&lt;/a&gt;</text></item></parent_chain><comment><author>lukego</author><text>I am a Snabb hacker and I see things differently. Ethernet I&amp;#x2F;O is fundamentally a simple problem, DPDK is taking the industry in the wrong direction, and application developers should fight back.&lt;p&gt;Ethernet I&amp;#x2F;O is simple at heart. You have an array of pointer+length packets that you want to send, an array of pointer+length buffers where you want to receive, and some configuration like &amp;quot;hash across these 10 rings&amp;quot; or &amp;quot;pick a ring based on VLAN-ID.&amp;quot; This should not be more work than, say, a JSON parser. (However, if you aren&amp;#x27;t vigilant you could easily make it as complex as a C++ parser.)&lt;p&gt;DPDK has created a direct vector for hardware vendors to ship code into applications. Hardware vendors have specific interests: they want to differentiate themselves with complicated features, they want to get their product out the door quickly even if that means throwing bodies at a complicated implementation, and they want to optimize for the narrow cases that will look good on their marketing literature. They are happy for their complicated proprietary interfaces to propagate throughout the software ecosystem. They also focus their support on their big customers via account teams and aren&amp;#x27;t really bothered about independent developers or people on non-mainstream platforms.&lt;p&gt;Case in point: We want to run Snabb on Mellanox NICs. If we adopt the vendor ecosystem then we are buying into four (!) large software ecosystems: Linux kernel (mlx5 driver), Mellanox OFED (control plane), DPDK (data plane built on OFED+kernel), and Mellanox firmware tools (mostly non-open-source, strangely licensed, distributed as binaries that only work on a few distros). In practice it will be our problem to make sure these all play nice together and that will be a challenge e.g. in a container environment where we don&amp;#x27;t have control over which kernel is used. We also have to accept the engineering trade-offs that the vendor engineering team has made which in this case seems to include special optimizations to game benchmarks [1].&lt;p&gt;I say forget that for a joke.&lt;p&gt;Instead we have done a bunch more work up front to first successfully lobby the vendor to release their driver API [2] and then to write a stand-alone driver of our own [3] that does not depend on anything else (kernel, ofed, dpdk, etc). This is around 1 KLOC of Lua code when all is said and done.&lt;p&gt;I would love to hear from other people who want to join the ranks of self-sufficient application developers. Honestly our ConnectX driver has been a lot of work but it should be much easier for the next guy&amp;#x2F;gal to build on our experience. If you needed a JSON parser you would not look for a 100 KLOC implementation full of weird vendor extensions, so why do that for an ethernet driver?&lt;p&gt;[1] &lt;a href=&quot;http:&amp;#x2F;&amp;#x2F;dpdk.org&amp;#x2F;ml&amp;#x2F;archives&amp;#x2F;dev&amp;#x2F;2016-September&amp;#x2F;046705.html&quot; rel=&quot;nofollow&quot;&gt;http:&amp;#x2F;&amp;#x2F;dpdk.org&amp;#x2F;ml&amp;#x2F;archives&amp;#x2F;dev&amp;#x2F;2016-September&amp;#x2F;046705.html&lt;/a&gt;
[2] &lt;a href=&quot;http:&amp;#x2F;&amp;#x2F;www.mellanox.com&amp;#x2F;related-docs&amp;#x2F;user_manuals&amp;#x2F;Ethernet_Adapters_Programming_Manual.pdf&quot; rel=&quot;nofollow&quot;&gt;http:&amp;#x2F;&amp;#x2F;www.mellanox.com&amp;#x2F;related-docs&amp;#x2F;user_manuals&amp;#x2F;Ethernet_A...&lt;/a&gt;
[3] &lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;github.com&amp;#x2F;snabbco&amp;#x2F;snabb&amp;#x2F;blob&amp;#x2F;mellanox&amp;#x2F;src&amp;#x2F;apps&amp;#x2F;mellanox&amp;#x2F;connectx4.lua&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;github.com&amp;#x2F;snabbco&amp;#x2F;snabb&amp;#x2F;blob&amp;#x2F;mellanox&amp;#x2F;src&amp;#x2F;apps&amp;#x2F;mell...&lt;/a&gt;</text></comment>
<story><title>Capturing Millions of Packets per Second in Linux without Third-Party Libraries</title><url>http://kukuruku.co/hub/nix/capturing-packets-in-linux-at-a-speed-of-millions-of-packets-per-second-without-using-third-party-libraries</url></story><parent_chain><item><author>revelation</author><text>This must be the 10th blog post to land on HN on the same topic, and they all walk through the same steps and all use the same hardware (ixgbe), which is by the way a hard prerequisite to make much of these strategies effective.&lt;p&gt;In any case, stop reinventing the wheel, just use a library purpose-made:&lt;p&gt;&lt;a href=&quot;http:&amp;#x2F;&amp;#x2F;dpdk.org&amp;#x2F;&quot; rel=&quot;nofollow&quot;&gt;http:&amp;#x2F;&amp;#x2F;dpdk.org&amp;#x2F;&lt;/a&gt;</text></item></parent_chain><comment><author>rdtsc</author><text>Depending what you are doing, with latencies (or throughput) in that range, sticking a black box  library in there right away might not be the best idea always. Doing what the author did is also a way to learn how things work. Eventually the library might be the answer, but if I had to do what they did, I would do it by hand first as well.</text></comment>