The Snabb Switch crew are starting to work on support for basic handling of packets on 100G NICs. However...

> With the new CPUs tending to increase the core count while the CPU frequency goes down, we'll get less and less "CPU cycles per packet". For example E5-2699v3 45M is 18 [email protected]. 10Gbps with 256 byte packets is achieved with 4.53Mpps, this makes ~500 clocks per packet on this CPU. Now make this 100Gbps and you get 50 clocks. You get this budget to receive, process and send the packet. 50 sounds pretty low to me.

Numbers refer to using only a single core. That particular CPU has 18 cores and 36 hardware threads.

https://groups.google.com/forum/m/#!topic/snabb-devel/pDd_uB...

Normally the solution is to have the NIC give you multiple receive queues and then tie each queue to a different core, meaning you get a packet on each core every time you clock them off the NIC. Increasing CPU cores gives you a massive win when you do that.

(On a hardware note, increasing cores and decreasing frequency makes the CPU look more like an ASIC :) )

Did you actually RTFA?

> The only reason I use “real” network gear anymore is ... for core routing 10gbps links.

Article is old; situation in 2016 might be different.

Probably not. All of the big vendors use some sort of hardware acceleration to achieve >= 10gb.

There's some progress, though (like PF_RING in Linux and netmap on FreeBSD).

if by “multiple” you mean 2x, then yes ;)

still, you need some tweaking or things like dpdk/openonload/vma/etc...