The programmability and configurability of a Broadcom StrataDNX™ switch presents unique complexities to developers who want to get the most out of the switch. Setting a SoC (System on a Chip) property to the right value can have a profound effect on features and resource consumption.
The optimal design of an application with the flexible pipeline architecture of a DNX switch requires a lot of knowledge and thought in selection of features.
Configurability:
For example, if we consider supporting IP Multicast on a DNX switch, entries could be in any of LPM/TCAM/LEM databases. The choice of databases depends on whether the customer wants to have IP Multicast enabled for:
- IPv4 or IPv6, or both
- Both ASM (Any-Source Multicast) and SSM (Source-Specific Multicast), or either one
- Multicast RPF (Reverse-Path Forwarding)
- L2 Multicast fallback
The developer must make other configuration decisions. For example, do we choose ingress/egress/fabric replication or a combination of all these? Additionally, members’ copy-unique-data can take different formats that enables different types of encapsulation possible on each copy of a Multicast group.
Wonder why the SDK throws a “Table full” error even though the database is under-utilized?
Wonder why some features are mutually exclusive?
Below are some of the key areas IP Infusion’s customers find that our expertise adds significant value to their products:
Configurability of commonly used memories:
- KBP Memory: Although this memory is intended for storing entries of Longest Prefix Match format, it can also be used as a direct-indexed table.
- LEM (Large Exact Match Database):Even though it is well known as Exact Match table, it can also be used to store prefixed route entries.
-
TCAM (Ternary Content-Addressable Memory): This memory brings a lot of flexibility in terms of matching packet header data or pipeline metadata or passing lookup results from ingress to egress.
Accesses per Packet: Understanding database limitations on packet lookup is essential when the same database is holding multiple information for your application. For example, some of the unicast forwarding features contend for the same memory, resulting in mutual exclusion of each other.
The same database can be accessed by different pipeline blocks, thus the permitted lookup count per block must be carefully utilized. For instance, lookup on TCAM from one block does not impact the number of possible lookups on TCAM from another block.
These databases have limitations on the number of times a lookup can be performed for a packet. Knowing this information helps in designing the application.
Programming the SDK:
The programmability of DNX chips enables the customer to use them for a variety of applications with different market segment needs. These diverse applications require changes in the way the SDK defines database keys and the way it populates packet meta data.
It is important to design these customizations in a way that will be compatible with any new SDK releases.
Algorithm:
There is always more than one way of solving a specific need. Choosing one approach over another is mainly driven by the customer use-case and what resources and limitations the customer can trade-off.
IP Infusion has developed an algorithm that can be applied to major use-cases and needs of customer applications in order to:
- Enable customers to consider the right approach among the possible options
- Enable customers to make informed decisions, (especially to avoid surprises during any feature additions) to avoid poor utilization of chip’s capabilities
- Make best use of available memory and
- Support maximal features in the forwarding pipeline
These are some of the areas that IP Infusion is assisting its clients to accelerate their design and development. This is possible because of the experienced engineers’ deep understanding of the supported features and capabilities of DNX chip sets.