There’s an article on internetnews.com by Sean Michael Kerner on the new routing architecture in FreeBSD 8.0:
“Though the open source FreeBSD operating system has changed in many aspects over the last 16 years of its life, one item that has remained relatively static is its underlying network routing architecture.
No more: It’s getting an overhaul with the upcoming FreeBSD 8.0 release.
FreeBSD 8.0, due out next month, will include a new routing architecture that takes advantage of parallel processing capabilities. According to its developers, the update will provide FreeBSD 8.0 with a faster more advanced routing architecture than the legacy architecture.
It’s an important change for FreeBSD, which has emerged as a key open source operating system for networking vendors, with players like Juniper,Coyote Point, Blue Coat and others offering their own network operating systems that are based on FreeBSD.
The new routing architecture was written Qing Li, senior architect at Blue Coat, as a way to give back to the open source community.
“Blue Coat’s ProxySG networking kernel was partially derived from the FreeBSD kernel. Blue Coat is a sponsor of my open source development work, so this is a good way to contribute to the open source community.”
Li told InternetNews.com
The new routing architecture in FreeBSD 8 is also about optimization, as it reduces data dependencies across networking layers. The end result is a routing architecture that can take better advantage of multi-core, parallel processing CPUs.
“The new routing technology works on both multi-core as well as single-core CPUs. The performance gain is most visible in the multi-core situation, though.”
Li said.
But making changes also has important implications for BSD 8.0, since a key goal of the release is about ensuring a degree of compatibility with prior releases and the existing software ecosystem.
“Since the rewrite affects fundamental packet processing and the operation of protocols within the networking kernel, I had to ensure regression risk was low and compatibility was high,” Li said. “For example, those applications that are part of the ports, which interact with the kernel (e.g. retrieving the routing information, waiting for notification about routing table changes ) will continue to compile and operate semantically correct.”
In a technical paper that Li is publishing and talking about today at a conference in Spain, Li explained that the legacy version of the FreeBSD routing architecture actually reduced parallelism on SMP (define) and parallel architectures.
“As a result of the dependency between L2 and L3 (define), the processing through these two layers was single-threaded. A common parallel TCP/IP protocol stack design is to allow L2 and higher layer processing to run independently of each other, having each processor managing different protocols. The aforementioned locking contention increased processor stalling and prevented one from benefiting from more advanced hardware platforms.”
Li wrote in his paper
According to Li, contention locks consumed as much as 47 percent of a CPU’s time with the legacy routing architecture, determined through a test with eight transmitting threads.
“With the new split L2/L3 design, the L2 and L3 references can be cached in the protocol control block for connected sockets or in a flow table for unconnected sockets and forwarding. Thus we see that very little of the CPU time is now spent in the locking primitives even when there are [eight] transmitting threads.”
Li wrote.
The whole article can be read here.
The U.K. Unix and Open Systems User Group (UKUUG) is hosting the 
James Nixon has a post about the 
The 
The 
Recent Comments