snabb

> If all of these routers adopted this, my lowly traffic would have to read from main memory on each route lookup... yes, but current COTS hardware, via userspace networking can very easily saturate a 10g interface at 64b packet-size / core. imho, it is the convergence of a large number of advances in COTS hardware over the last couple of years, that has changed the field to mostly a software problem rather than a combination of hardware + software one. when you have proprietary hardware, software tends to be more or less proprietary, which is where most of the networking vendors are currently. a large number of projects are actively attacking this space e.g. snabb(https://github.com/lukego/snabb), routebricks (http://routebricks.org/) etc.

No. You could build dtrace with software like this, whereas the entire stack you mentioned only cares indirectly about per-message cycle overhead. This is for when your tight loop, like your routing engine or game loop, wants to kick out numbers at timestamps as fast as it can and other software deals with making them presentable. It's a great technique. This is built for networking software/hardware, where every cycle matters, and is actually extremely useful to me in a couple domains. I'm impressed disabled messages only sink five cycles so I assume there was hand tuning done here. Edit: And I'm right, it's a hand tuned logical compare (cool): https://github.com/lukego/snabb/blob/timeline/src/core/timel... If you want reasons to learn assembly, there you go. Too few folks wielding it in typical Web operations, where it would be extraord