Net processors are in evaluation

o longer just paper architectures, network processors are coming off the fab line and into the hands of customers, which are designing them into systems for production. For many OEMs choosing to go this route, it's a time to hunker down with their vendors, evaluate the cornucopia of architectures and software tools, and make a decision.

The advent of the network processor means networking OEMs no longer have to rely solely on ASICs to get wire-speed packet processing. But for better or worse, customers face a dizzying array of choices. Though many of these processors are alike in that they divide the data path among many, multithreaded processors, the devil is showing up in the details. A wide range of microengines, software, hardware accelerators, development environments and external memory support makes the task of choosing a network processor a weighty matter.

For Atoga Systems Inc. (Fremont, Calif.), choosing the right software environment was among its first priorities when it was selecting an NPU vendor for a system that combines Internet Protocol, Sonet and wave-division multiplexing in one box. From the beginning the company had decided that using an NPU was a must.

Atoga looked at three vendors, eventually settling on a member of Motorola's C-Port architecture, the C-5, which Atoga believed was furthest along at that point. "The environment for developing code was more complete and its basic engine had more horsepower and flexibility than its competitors at the time," said Steve Shaffer, vice president of hardware engineering at Atoga.

The software environment is based on the GNU open-source C compilers, "which means that there are a huge amount of development tools for it. And it's proven to be a flexible compiler," Shaffer said.

Software support is turning out to be one of the central issues surrounding network processors. Aside from adding their own C-language support or building in so-called C intrinsics, NPU vendors are trying to hash out high-level, industry-standard application-programming interfaces (APIs) that could work across a multitude of architectures.

The Network Processor Forum (NPF), which consolidated the efforts of two other standards groups in the area of NPUs, has set out to develop such high-level APIs. Some industry observers believe the group should also take on developing low-level, application-specific APIs to generate more interest from developers to write code that can be used across different devices. "To date, the NPF has been working on APIs, but not the low-level programming environment on the network processor itself," said Bob Husak, chief technology officer and co-founder of C-Port Corp., which was acquired by Motorola. "We think it will be important for the group to do that."

There may be limits to how far the NPF can go. Steve Longoria, director of marketing strategy for IBM Microelectronics' network processor group, said there may be too much diversity to support low-level APIs. "The lower you get, the closer you get to the differences in the hardware architectures," Longoria said. "They were having a hard time getting a consensus that didn't require too much of a least common denominator that would have sacrificed performance."

At the highest level, many network processors are similar in that they use many processor cores, allowing incoming packets to be parsed out and treated separately. In many cases, these microengines are based on tiny RISC engines that can be programmed individually.

Unlike the PC arena, developers don't have the luxury of a BIOS to handle many of these lower-level programming tasks. The fact that many of these microengines are multithreaded further complicates matters, because the programming models for these processors are still considered to be new.

Still, faced with the choice of going with a proprietary ASIC or writing low-level code for these microengines, many developers will choose the latter, Longoria said. "I wouldn't say [developers] like it, but they know how to do it," he said. "There's a growing familiarity in the networking world at developing low-level software."

In the opinion of Bob Gohn, vice president of marketing at C-Port, that doesn't go far enough. Gohn said the best approach is for chip vendors to choose C-level tools and software first, then decide on the hardware. Though many NPUs try to ease the programming burden by using C intrinsics, that does not go far enough. Having to express these special instructions in C language "and then generate the appropriate hypertweaked instructions is a hard or impossible task," he said.

That's not the only bone of contention. While most NPU vendors aim to conquer the control plane and the data plane, some believe the network processor should have a more modest role.

Andy Keane, vice president for the microprocessor division at PMC-Sierra Inc. (Burnaby, British Columbia), likened the network processor to failed attempts to drive programmable media processors into the PC. In this sense, programming graphics or modem functions turned out to be a fruitless exercise because there was a plentiful supply of dedicated hardware that could do the job better.

"These kinds of devices always lose on cost or performance, or to an ASIC that's dedicated to standard functions. We view this situation as being the same, and the network processor as an architectural experiment," Keane said.

PMC said it is sticking to the status quo by providing a modified, general-purpose MIPS-based processor for the control plane, and providing specialized hardware engines such as classifier chips for the data plane.

Network processor vendors, not surprisingly, take a different view. "We disagree with the ultimate premise that you need a bag of parts to do data-path functions," C-Port's Gohn said. "We were born to do data plane."

Intel Corp., for its part, believes ever-increasing processing horsepower will allow its NPU to do both. The company is banking on a forthcoming version of its Xscale processor, a derivative of the existing StrongARM architecture. Intel will integrate the new Xscale into its IXP processor line, which will run as high as 1 GHz and be tightly coupled with its individual microengines. Nabil Damouny, director of marketing for the access and switching processor division at Intel, said it was a "myth" that programmable NPUs won't be able to keep up:"In the core, we're going to be running close to a gigahertz on the control plane, and we're going to have many more microengines than we would have at the edge. When you get to the core it becomes a transport issue; you don't need to make too many decisions there."

But boosting the frequency of a network processor's central processing unit isn't a panacea, IBM's Longoria said. "This is not a megahertz game but a game of who moves the most packets. Having higher megahertz is a brute-force way of enhancing performance," he said.

IBM is promoting its on-board PowerPC device on its high-end PowerNP processor line to handle a "lightweight" control plane. For more elaborate systems, the company is proposing an external PowerPC with a PCI interface.

NPU makers however, may have some work to do to persuade customers that the devices can handle the higher speeds. "Network processors are ideally used for intelligent handling at the edge of the network, where the speeds are not as heavy as that of the core," said P.G. Menon, vice president of marketing at Atoga.

Outside of their own architecture, NPU vendors are also struggling with the question of which external memory architecture to support. In packet processing, routing tables are often stored in external DRAM, and it may take two or three DRAM accesses to locate an address, according to Linley Gwennap, principal analyst at the Linley Group (Mountain View, Calif.).

NPU vendors say there is still a pressing need to increase bandwidth and reduce the latency of DRAMs. Among the candidates are double-data-rate SDRAM, Rambus, fast-cycle RAM and, soon, reduced-latency DRAM. One of the biggest concerns is whether these architectures will survive in the long term. The selection process "is causing as much angst as it has in the desktop PC business," said C-Port's Husak. "One issue in implementing communications products is that those products tend to live a lot longer than PCs do."