Xelerated Xpress

When There Is a Special Purpose

Network processors are very flexible. They can be programmed for any type of data plane services. Every customer project is unique; all organizations want to compete with features and functionality as they continue to come up with new, innovative ways to make the most out of NPU silicon.

Still, there are limitations to what network processors can do. They are developed for a special-purpose; to process packets very efficiently. What they do, they do very well. But if you want to accomplish anything other than process packets, you will need another type of processor. General-purpose multicore processors would be the choice. But can’t they be used for packet processing as well?

For a deep-dive to this subject, I recommend reading Håkan Zeffer’s and my recent article in Electronic Design. We compare the differences between the special-purpose dataflow architecture, which is found in all Xelerated NPUs, and general-purpose multicore architectures that are popular in today’s server architectures. Both have their merits, and a comparison should be made for the target application. When looking to the architectures, you can start to calculate how efficient the different approaches are for different types of applications. I hope you find the conclusions interesting.

by Per Lembre on May. 28th, 2010

| Comment

Multi-core Disappointment – Here We Go Again

It is time this industry learns from historic mistakes. If not, we may spend huge amounts in engineering efforts only to discover the path taken is a dead end.  I read a recent article by Simon Stanley of Light Reading, and in it his research indicates that multi-core processors are being evaluated from applications in the network processing field. I don’t see this trend when talking to the major network equipment vendors, and this might be  because they also remember what multi-core processors couldn’t deliver ten years ago.

Those who are seriously evaluating multi-core architectures for packet processing should be prepared for some surprises. Again. The same evolution happened several times before with separate processors brought together in a multi-processor architecture on the same die to scale processing performance.  Have people already forgot about why previous multi-core proposals for packet processing did not fly?

First, multi-core architectures consume a lot of power. Second, they are not designed for deterministic wirespeed performance. Third, they are difficult to program efficiently – making it hard to meet the performance requirements in modern packet processing applications.  And using ANSI-C does not help the inefficiency and performance challenges.

Multi-core processors are designed for general purposes, and they are therefore not optimized for packet processing.  They lack the necessary service density. Xelerated’s Dataflow Architecture, in contrast, was designed to solve the challenge of combining programmability and super-efficient packet processing. It is a linearly scalable wirespeed-by-design processing architecture with low power and a great amount of service density.

Support for 40 or 100 G interfaces does not say anything about the device’s ability to perform a meaningful application at these speeds. And when looking into the requirements in advanced Carrier Ethernet, Fiber Access or Mobile Backhaul applications, general-purpose multi-core designs continue to fall short. To give you an idea: Xelerated’s new HX330 has over 900 percent greater service density compared to the most high-end multi-core processor on the market. That is, it has 9 times the processing capacity for network and packet processing!

It is time to learn from history. Multi-core architectures have a bright future in general applications, for the server and consumer markets. Here is where they belong – processing applications, not processing packets.

There is a reason why 20+ NPU vendors that spent multi-million dollars in multi-core architectures failed to deliver a commercial and technically viable option to the networking industry. This history is just ten years away. I’m confident network equipment vendors have a longer memory than this.

by Thomas Eklund on Apr. 7th, 2010

| Comment

Dataflow OAM

For service providers, Operations Administration and Maintenance (OAM) is business critical. OAM is a set of features required to operate the network efficiently. Links and nodes are contineously monitored for consistent traffic forwarding. Anomalies and faults are announced (and protection switching is carried out). Access switches and CPEs are automatically configured.

All these tasks are operated in the background, invisible to the end-user, and in most cases even to the personell at the Network Operating Centre. Every node in the network is configured to automatically carry out its OAM tasks. Reporting back to the centralized operations systems is limited to faults and status message updates at regular intervals.

At the node level, all OAM tasks need to be implemented in a highly scalable manner with limited or no performance hit of the user data traffic. A few years back, these tasks were implemented by the control plane running on the CPU. But with the  processing power needed for OAM in today’s modern Carrier Ethernet networks, the data plane on the Network Processor (NPU) has to significantly offload the CPU.

Take Ethernet link OAM as defined in IEEE 802.1ag. It is used to trigger protection switching in e.g. PBB-TE, and requires significant support by the data plane to operate efficiently. Every second, each Management End Point (and a node can support several hundreds of these) generates 300 Control Check Messages (CCM) to its peers.

At Xelerated, we have taken an holistic approach to all OAM operations. The control plane is obviously still in charge for all OAM tasks. But when monitoring links and forwarding states, we are really interested in how the data plane behaves. It should ultimately be able to collect the right information and hand it to the reqeusting entity without having to involve the CPU of the system. Even if the control plane goes down, these tasks should run without any interference.

Similar processes are carried out for routing and switching table maintenance, hardware health checks and memory repairs. On a node level, these tasks are hugely important , and when you think about it, they have a lot in common with service and link OAM.

In the last few months we have got some good feedback on our approach to OAM. For developers used to the simplistic programming model used when coding the dataflow architecture featured in all Xelerated devices, programming OAM is like programming any other part of the data plane. Maybe this is what is best about our OAM approach. OAM isn’t a new area requiring a new set of tools and software. It is an inherent part of the data plane. So all we had to do was to allow the programmable pipeline to be programmed and configured by packets generated by the control plane, or be triggered by an OAM packet arriving from the network. These control messages triggers an OAM program running in the pipeline thereby allowing the rich set of resources to be accessed in a timely manner for any type of OAM task.

We haven’t coined Xelerated’s OAM approach yet, but I’m leaning towards Dataflow OAM. Below is a first draft on how the Dataflow OAM functionality can be presented. Comments, anyone?

by Per Lembre on Sep. 15th, 2009

| Comment