Van Jacobson's network channels

Van Jacobson's network channels

[Posted January 31, 2006 by corbet]

Your editor had the good fortune to see Van Jacobson speak at the 1989USENIX conference. His talk covered some of the bleeding-edge topics ofthe time, including TCP slow start algorithms and congestion avoidance. Itwas the "how Van saved the net" talk (though he certainly did not put itin those terms), and, many years later, the impression from that talkremains. Van Jacobson is a smart guy.

Unfortunately, attending Van's talk at linux.conf.au this year was not inthe program. Fortunately, DavidMiller was there and listening carefully. Van has figured out how thenext round of networking performance improvements will happen, and he hasthe numbers to prove it. Expect some very interesting (and fundamental)changes in the Linux networking stack as Van's ideas are incorporated.This article attempts to cover the fundamentals of Van's scheme (called"channels") based on David's weblog entry and Van's slides[PDF].

Van, like many others, points out that the biggest impediment toscalability on contemporary hardware is memory performance. Currentprocessors can often execute multiple instructions per nanosecond, butloading a cache line from memory still takes 50ns or more. So cachebehavior will often be the dominant factor in the performance of kernelcode. That is why simply making code smaller often makes it faster. Thekernel developers understand cache behavior well, and much work has goneinto improving cache utilization in the kernel.

The Linux networking stack (like all others) does a number of things whichreduce cache performance, however. These include:

• Passing network packets through multiple layers of the kernel. When a packet arrives, the network card's interrupt handler begins the task of feeding the packet to the kernel. The remainder of the work may well be performed at software interrupt level within the driver (in a tasklet, perhaps). The core network processing happens in another software interrupt. Copying the data (an expensive operation in itself) to the application happens in kernel context. Finally the application itself does something interesting with the data. The context changes are expensive, and if any of these changes causes the work to move from one CPU to another, a big cache penalty results. Much work has been done to improve CPU locality in the networking subsystem, but much remains to be done.

• Locking is expensive. Taking a lock requires a cross-system atomic operation and moves a cache line between processors. Locking costs have led to the development of lock-free techniques like seqlocks and read-copy-update, but the the networking stack (like the rest of the kernel) remains full of locks.

• The networking code makes extensive use of queues implemented with doubly-linked lists. These lists have poor cache behavior since they require each user to make changes (and thus move cache lines) in multiple places.

To demonstrate what can happen, Van ran some netperf tests onan instrumented kernel. On a single CPU system, processor utilization was50%, of which 16% was in the socket code, 5% in the scheduler, and 1% inthe application. On a two-processor system, utilization went to 77%,including 24% in the socket code and 12% in the scheduler. That is a worstcase scenario in at least one way: the application and the interrupthandler were configured to run on different CPUs. Things will not alwaysbe that bad in the real world, but, as the number of processors increases,the chances of the interrupt handler running on the same processor as anygiven application decrease.

The key to better networking scalability, says Van, is to get rid oflocking and shared data as much as possible, and to make sure that as muchprocessing work as possible is done on the CPU where the application isrunning. It is, he says, simply the end-to-end principle in action yetagain. This principle, which says that all of the intelligence in thenetwork belongs at the ends of the connections, doesn't stop at thekernel. It should continue, pushing as much work as possible out of thecore kernel and toward the actual applications.

The tool used to make this shift happen is the "net channel," intended tobe a replacement for the socket buffers and queues used in the kernel now.Some details of how channels are implemented can be found in Van's slides,but all that really matters is the core concept: a channel is a carefullydesigned circular buffer. Properly done, circular buffers require no locksand share no writable cache lines between the producer and the consumer.So addingdata to (or removing data from) a net channel will be a fast,cache-friendly operation.

As a first step, channels can be pushed into the driver interface. Anetwork driver need no longer be aware of sk_buff structures andsuch; instead, it simply drops incoming packets into a channel as they arereceived. Making this change cuts the CPU utilization in the two-processor caseback to 58%. But things need not stop there. A next logical step would beto get rid of the networking stack processing at softirq level and to feedpackets directly into the socket code via a channel. Doing that requirescreating a separate channel for each socket and adding a simple packetclassifier so that the driver knows which channel should get each packet. The socket code must also be rewritten to dothe protocol processing (using the existing kernel code). That changedrops the overall CPU utilization to 28%, with the portion spent at softirq level dropping to zero.

But why stop there? If one wants to be serious about this end-to-endthing, one could connect the channel directly to the application. Saidapplication gets the packet buffers mapped directly into its address spaceand performs protocol processing by way of a user-space library. Thiswould be a huge change in how Linux does networking, but Van's resultsspeak for themselves. Here is his table showing the percentage CPUutilization for each of the cases described above:

	Total CPU	Interrupt	SoftIRQ	Socket	Locks	Sched	App.
1 CPU	50	7	11	16	8	5	1
2 CPUs	77	9	13	24	14	12	1
Driver channel	58	6	12	16	9	9	1
Socket channel	28	6	0	16	1	3	1
App. channel	14	6	0	0	0	2	5

The bottom line (literally) is this: processing time for the packet streamdropped to just over 25% of the previous single-CPU case, and less than 20%of the previous two-CPU behavior. Three layers of kernel code have beenshorted out altogether, with the remaining work performed in the driverinterrupt handler and the application itself. The test system runningwith the full application channel code was able to handle twice thenetwork bandwidth as an unmodified system - with the processors idle mostof the time.

Linux networking hackers have always been highly attentive to performanceissues, so numbers like these are bound to get their attention. Beyondperformance, however, this approach promises simpler drivers and areasonably straightforward transition between the current stack and afuture stack built around channels. A channel-based user-space interfacewill make it easy to create applications which can send and receive packets using any protocol. If Van's results hold together in a "real-world"implementation, the only remaining question would be: when will it bemerged so the rest of us can use it?