The ONL NPR Tutorial

NPR Tutorial >> Router Plugins

TOC

Plugin Basics

NPR plugins provide users a powerful mechanism for extending the functionality of a basic NPR. In the simplest approach, users can insert pre-written plugins that act on packets as they move through the NPR and then direct selected packets to the plugin using a filter. For example, you can send TCP packets to the delay plugin to emulate propagation delay. In its most general form, users can write their own plugins. For example, a user could replace the entire functionality of the Queue Manager by sending all packets to plugins that implement a completely different strategy for scheduling packets.

As shown above, packets arriving to the NPR pass through the PLC (Parse, Lookup and Classify) module, and then normally pass through the Queue Manager and Header Formatting blocks before being transmitted out to the network. However, users can use a filter to direct packets to plugins for customized packet processing. For example, plugins can be used to:

• Examine packet headers and/or bodies
• Modify packet headers and/or bodies
• Delay packets
• Produce additional packets
• Change the normal packet forwarding action

Typically (path 1), after a packet has been processed by one or more plugins, the packet can be reinjected into the normal packet path by sending it to the Queue Manager. But if a plugin is used only for monitoring and the packet is a packet copy produced by an auxilliary filter, the plugin might want to drop the packet (path 2). A third possibility is that after processing the packet, the plugin might reinject the packet (with or without modification) back into the packet path for reclassification (path 3). In this reclassification scenario, the NPR also allows the user to tag a packet with a positive integer tag which can be used during reclassification. Some of these capabilities are demonstrated by predefined plugins.

As shown in the RLI plugin dialogue window above, plugin users can:

• Add (Load) a plugin into one of the five plugin MEs
• Delete (Unload) a plugin from a ME
• Send a command (message) to a plugin
• Add plugin data to a graph
• Add a plugin directory

Although this section discusses how to use predefined plugins, it is instructive to see some of the things that are involved in writing your own plugin. A plugin developer writes a plugin in microengine (ME) C which is the standard C-like language provided by Intel for use on MEs. The most important differences between microengine C and ANSI C are dictated by the IXP architecture. First, there is no dynamic memory allocation or use because there is no OS or other entity to manage the memory. Second, all program variables and tables must be explicitly declared to reside in a particular type of memory (registers, ME local memory, scratchpad, SRAM, DRAM) as there is no caching. Third, there is no stack and hence no recursion. And finally, you can have up to eight threads per ME, but these threads must share control explicitly (i.e., there is no preemption).

To help users who are unfamiliar with this programming environment, we have developed a programming framework that lowers the entry barrier for writing simple to moderately complex plugins. Note that users are not required to use the framework. Users who are already experts with the IXP can do whatever they wish with the five plugin MEs. The framework consists of a basic plugin structure that handles tasks common to most plugins and a plugin API that provides many functions that are useful for packet processing.

To support plugin developers, we provide a plugin API. The API consists of helper functions for common packet processing steps as well as functions that hide some of the complexity of interacting with packets and packet meta-data. Some examples are:

• Read packet headers from DRAM into local structures
• Increment local counters
• Read/write meta-data
• Prepare packets for sending to other blocks in the router
• Compute a checksum

A plugin developer writes plugin code in the microengine C language and then compiles the code into a loadable module. In the simplest case, the developer only needs to write the packet handling part of the code; i.e., the part that gets the packet (actually the meta-packet), processes the packet, and then puts the packet into the input buffer of the next NPR component (e.g., Queue Manager). The plugin developer typically writes new plugin code by copying the code of some simple plugin (e.g., count) and then writes the code in the handle_pkt_user() function. For example, in the predefined count plugin, the function handle_pkt function does the necessary I/O and then calls handle_pkt_user to do the packet processing (incrementing a counter). In most cases, the control message handling code from a simple plugin can be easily customized for most applications.

NPR Tutorial >> Router Plugins	TOC