Capacitación

Summarising the two architectures outlined in previous section, it can be seen that the major trade-off within NP design is how to maximise performance while maintaining flexibility. Providing a purely PE-based dataplane would maximise flexibility but certain tasks such as encryption are difficult to implement in software at the required performance levels. On the other hand, an architecture in which the PE only provides basic functional- ity in software with a large amount of hardware accelerated blocks would limit the ability to update the services and algorithms implemented on the router. Both the Intel and Cav- ium architectures utilise a RISC-based PE structure with hardware blocks augmenting the programmable data plane. Examining other commercial architectures, the EZchip NP-1 [38] and Xelerated X11q [39] can be argued to represent two architectures in which design flexibility is reduced in order to maximise performance. Both utilise a strictly pipelined layout (in the case of EZchip the architecture is parallel-pipeline), with the PEs heav- ily optimised for NP applications. Each stage of the Xelerated architecture can execute only 4 instructions. Despite the large variation across commercial architectures, a num- ber of architectural techniques have evolved to become common features within network

processor design.

2.3.3.1 Multicore Processing

At both a packet and flow level, parallelism provides a method of scaling performance to meet higher bandwidth demands. Although the number of PEs in most NPs has been around the order of 4-16 ([34],[36],[40]), a number of architectures stand out as employ- ing a substantially higher degree of parallelism. Firstly, the Netronome NFP-3200 [41] and Cisco QuantumFlow [42] utilise 40 processing engines. The superscalar design em- ployed by EZchip in the NP-2 and NP-3 [43] NP also exploits large scale parallelism (the number of PEs is not available in the public domain). The Xelerated X11 NP provides neither flow nor packet level parallelism and instead uses 800 Packet Instruction Set Com- puters (PISC) engines arranged in a linear pipeline [39]. Furthermore, the Silicon Packet Processor (SPP) developed by Cisco includes 188 separate RISC engines per chip [44].

2.3.3.2 NP Interconnection

Despite NPs employing a multiprocessor architecture, there has been little research into bus topologies for NP systems. Weng and Wolf proposed a mechanism for distributing tasks across a parallel system but the underlying bus parameters were not examined [45], while Karim et. al. is, to the author’s knowledge, the only published work to examine bus topologies in NP systems [46]. For general purpose systems, communication systems between processors, memory and external devices has undergone more extensive research, with proposed and available bus systems optimised for low-cost [47], high performance when streaming data [48] or universality [49].

2.3.3.3 Integrated Networking Interface

To reduce the latency associated with packet ingress and egress operations, networking in- terfaces are integrated on-chip instead of being bridged to the network processor. Typical implementations include a means of connecting the network processor to a physical layer device such as a Gigabit Optical, Gigabit Media Independent Interface (GMII) or Packet

Over SONET (POS) SPI-4.2 interface [50]. Along with this physical device interface, some cases will include the Common Switch Interface (CSIX) to provide interconnection of the NP and a router switching fabric.

2.3.3.4 Multithread Processing

Providing a cheap method of minimising the cost associated with long latency operations, multi-threading lends itself to network processing in a number of ways. Firstly, the par- allelism outlined in Section 2.3.3.1 can be extended to include multi-threads. Secondly, applications suited to pipeline partitioning can be implemented as either a pipeline across multiple PEs or as a conceptual pipeline located on a single PE. Finally, multiple threads or contexts are reasonably cheap to implement. Requiring little interaction between the programmer and application, a context swap can be achieved by a single register swap, with only a small amount of control hardware needed to schedule each thread.

2.3.3.5 Control Plane (Host) Processing

In addition to the data-plane processing, routers also require a means of providing con- trol plane functionality. At a fundamental level, these control plane tasks include func- tions such as routing table updates, classification ruleset updates and adjustments to the scheduling functions, as well as processing non-standard packets (e.g. control information from other routers). More complex functions require implementing an operating system on the host Central Processing Unit (CPU) as a means of providing system control across the line card. While the Intel, Netronome and HIFN architectures implement an on-chip control plane processor, the remaining NPs typically provide either a specific port or a generic PCI interface between the NP(s) and a host CPU.

2.3.3.6 Integrated Memory Controller

For general purpose processing that is not sensitive to access latency, the memory subsys- tem is optimised for bandwidth rather than latency. Due to the low latency requirements of packet processing, NPs must perform fast memory operations in order to match the

minimum packet inter-arrival time [51]. Therefore, most NPs have integrated memory controllers in order to achieve lower latency. Furthermore, the low spatial locality of net- work applications also suggests that the optimisation of bandwidth for memory subsystem is not as effective in NP as in GPP architectures [52].

2.3.3.7 Hardware Accelerator

Offloading special applications that are relatively stable and suitable for hardware im- plementation has been adopted as an important method to achieve high performance. Hardware accelerators usually function as coprocessors and have the potential of being executed concurrently with other parts of the program. They can be implemented either private to or shared by the processing cores, or implemented as external devices interact- ing with the NP. Hardware acceleration is covered in more detail in section 2.5.2.