New approaches to network fast paths | Hacker News Reader

New approaches to network fast paths

lwn.net

41 pointssigna119 comments

> We will focus on in-kernel solutions for now. Indeed, user-space tools have a fundamental limitation: if they need to re-inject packets onto the network, they must again pay the expensive cost of crossing the kernel barrier

This is glossing a little quickly over user-space solutions.

If you are handling packets at the rate of which you thus need to put a kernel bypass in place, then there is chance that you can't afford the kernel to handle them on their way back onto the network.

The obvious solution is to kernel bypass this transmit side as well. All user-space tools offer this.

There are some control packets that will need to get back to the kernel, but those do not require that kind of speed.

And frameworks like dpdk provide a slow path to handle control back to the kernel.

netmap, too.

> And frameworks like dpdk provide a slow path to handle control back to the kernel.

yes they do, but the original statement was : "if they need to re-inject packets onto the network, they must again pay the expensive cost of crossing the kernel barrier"

i guess, the emphasis is on 'pay the expensive cost of crossing the kernel barrier'. the fact that such means exist, is not debated.

Fast path to me has always meant no software that runs on a general purpose CPU. It means the packet needs to traverse the device without being touched by software that runs on a general purpose CPU. ASIC or similar only.

The minute we start talking about fast-path in-kernel is when I realize that Linux folks and most networking folk who use the term have a different idea of what fast-path means. Still interesting, but not what I thought I would be reading.

Do most routers have ASICs that read the routing table then?

I don't know why you were downvoted, this is a good question.

Yes. The terms used in BGP are typically Router Information Base (RIB) and Forwarding Information Base (FIB). Generally speaking the FIB is stored in some type of memory that has a fixed lookup time and does not involve a general purpose CPU.

A case of only so many words in the English language. Easy to fix if we distinguish hardware fast path from the software variant.

Software fast paths are worth looking into since context switches are costly to the tune of thousands of CPU cycles [0,1]. Those thousands of CPU instructions going up in smoke could've done quite a lot of useful work.

[0] http://blog.tsunanet.net/2010/11/how-long-does-it-take-to-ma...

[1] https://gist.github.com/nelsnelson/3955759

DPDK is ascendant, similar moves are underway for storage.

The operating system is the new control plane.

Reply on news.ycombinator.com