Time to Clarify Service Density
This industry struggles with a communication issue. One of the most important aspects of network processing – service density – lacks a common definition, and because of this, there is no widely accepted way to measure it.
The density of processing resources, here illustrated by a part of the single pipeline of processor cores and engine access points featured in the Dataflow Architecture, defines how much services a chip can support.
We all know how to measure link bandwidth; we do this in Gigabits per second (Gbps). Likewise, we have a common understanding of how to measure the raw performance of packet processing; Megapackets per second (Mpps). But we don’t fully agree on how to measure the capabilities of parsing, classification and modification – important tasks which are performed by the network processor (NPU).
Over what is now a few generations of NPU development at Xelerated, it is fair to say we spend a large part of our system engineering on increasing service density. The first generation of NPUs, the X10q family, was initially released in 2002. It was a 40 Gbps NPU with 40-100 Mpps, depending on type. In the next generation, the X11 Family of NPUs, the greatest achievement was (yes, you are correct!), increases in service density. (Okay, some people may argue that the integration of more interface types and GE MACs was key to the success. But I still think the list of services and features the X11 performs – in parallel and in wirespeed – must be one of the greatest achievements in the industry at the time).
Now moving to the third generation, the HX family of NPUs. This is a 100 Gbps and 150 Mpps NPU family, which is significantly more than the X11, sure. But again, we make a giant leap forward in terms of service density. This means more instructions per packet and more lookup bandwidth per packet type. The result is that more services can be delivered in a single chip.
For the system vendors, making the correct assumptions on service density is one of the most strategic tasks for product management. There are many cases where the HX device consolidates three to four ingress and egress processing chips (be it custom ASICs or merchant NPUs) into one. It impacts COGS, margins, and in the end, the whole business case for the product.
The lack of a commonly accepted definition of service density makes the dialog between silicon and system vendors unnecessary blurred and full of misunderstanding.
So let us start the job of defining the term. I do not have a perfect answer to this. As can be seen at the Xelerated product pages, we measure service density only by comparing the capabilities of the different devices within the same family. As we lack a more general definition, we could not measure service density across product families. Yet.
The definition should take both the number of operations per packet and the classification of resources per packet into account. And another component also needs to be added to the equation: the packet processing needs to be achieved at wirespeed for a specified link rate. Without a hard performance target in terms of Mpps, the whole discussion just falls short. So let’s get the discussion rolling… for the evolving services in the metro space, next generation platforms will be dependent on this definition.
Comments
Your comment