Software Architecture for Network Processor Intel IXA Programming Framework

Weidong Shi Georgia Institute of Technology 2002

Plan

Software architecture for network processor Intel Internet Exchange Architecture ACE programming framework How to compile and run the simple count ACE app ilab network setup

Trends of Network Processing Hardware

Rajiv Khemani. Interfaces and Interoperability. Intel Corporation

Demand a software architecture that provides

programming functionality in both fast-path and slow path initializing & configuring fast-path functionality and exception handling

Slow and Fast Path Protocols Inside a Network Processor

http://www.intel.com

A Good Network Processor Software Architecture Should Achieve

Interoperability between different software components
Service portability
same service APIs on a range of processors

Hardware Abstraction
consistent software interfaces regardless of the
underlying hardware implementation

Extensibility
easy to add new service and protocol layer

Customability

Intel Internet Exchange Architecture

Flow based packet processing Reusable software building blocks (ACEs) Great portability, runs on IXP12xx, Intel CPU Extensible, app specific ACEs

Intel IXA SDK ACE Programming Framework.

Another View of IXA

Rajiv Khemani. Interfaces and Interoperability. Intel Corporation

ACE, the Building Block of IXA

Software component for processing packet
classifies the packets manipulates the classified packets

Service building blocks

ACEs can be chained to provision a service each ACE perform distinct steps of the services
Active Computing Element It is called Action Classification Engine in 2000

Packet Flow

Bernie Keany. Benefits of Software APIs for the Network Processing Market. Intel Architecture Labs

Target of upstream ACEs are bound to downstream ACEs. Packet flows from an upstream ACE to a downstream ACE.

Type of ACEs
User ACEs Developed by users

Library ACEs Predefined ACEs such as L2 bridging ACE and L3 forwarding ACE. Supplied by Intel or other third party developers.
System ACEs Platform dependent ACEs. Include interface ACEs (remember HW1?) and protocol ACEs (stack ACEs). ACEs implemented in Microcode are called MicroACEs. MicroACEs hide the underlying hardware details from other ACEs.

Classification & Action

An ACE does three things on a packet
Classifies it Acts on it Disposes of it

Rule
Rule check_src {ip.src==192.168.10.20} { action_one() } Rule check_http{tpc&&(tcp.sport==80)}{action_scan()} The meaning of rule check_src is: if source ip address is 192.168.10.20, then execute action function "action_one()"

Communicating with ACEs Role Query and monitor ACE status

such as traffic statistics

Control ACEs
such as Mac address and IP address set up, routing table entry insertion and removal

Object Management System

It is slow, not recommended for transferring packet data.

Intel IXA SDK ACE Programming Framework.

MicroACEs

Designed for fast-path processing

such as IP forwarding, network address translation, IP filtering

Has two logical components

a microcode part runs on microengines (microblock) a C/C++, NCL part (core component) runs on StrongArm where you do classification/action

Apps or other ACEs communicate with a ACE via the core component

Microblock
A microcode macro that either receives, sends, or operates on packets
#macro Counter()
.local input_port exception_code stats_addr DL_GetInputPort[input_port] immed[dl_next_block, 1] DL_SetQueueNum[input_port] immed32[stats_addr, _COUNT_STATS_BLOCK] Count_IncrementPacketCounter[stats_addr] .endlocal #endm

All microblocks inside the same microengine consists of a microblock group.

MicroACE Binding

Intel IXA SDK ACE Programming Framework.

Only static binding supported for MicroACEs Hard coded MicroACE connections (dispatch loop). For non-MicroACEs, binding can be configured through scripting.

Dispatch Loop
Each microblock sets two global registers
dl_buffer_handle dl_next_block handle for the current packet destination microblock number (if set IX_EXCEPTION, the packet is delivered to the ACE core component)

.while (1) DL_SASource[] .if (dl_buffer_handle == IX_BUFFER_NULL) br[Main_Dispatch#] .elif (dl_next_block == IPFILTER_TAG ) br[IPFilter#] .elif (dl_next_block == IPFWD_TAG) br[IPFwd#] .endif

Dynamic Binding of MicroACEs

Pros and Cons of dynamic binding What are required to support dynamic binding? NetBind on http://www.comet.columbia.edu/genesis/netbind/

Stack ACE

Intel IXA SDK ACE Programming Framework.

A kernel-mode Ethernet device driver implemented as a conventional ACE. To the Linux kernel, the stack ACE works as an Ethernet device, to other IXA modules, it is an ACE.

IXA SDK Installation

IXA SDK Setup

To use the GNU arm tool chain, update your path
PATH=$PATH:/usr/local/armbe/bin This allows you to use the cross compiler armv4b-unknow-linux-gcc

To access other IXA-specific compilers and binaries, add path

PATH=$PATH:/opt/ixasdk/bin

Export environment variables

export IXROOT=/opt/ixasdk export CONFIG=ARM_BE

Run IXA On the ilab BV Boards

All the IXA binaries, IXA scripts, and ACE binaries are stored in /opt/ixasdk/bin/arm-be All the ilab BV boards mount this directory under /net/hp31/ixpdev/exports-sdk2.0/opt/ixasdk/bin/arm-be Type ixstart ixsys.config to run an ACE app ixsys.config specifies ports and ACE binding

But you don't have permission writing to /opt/ixasdk/bin/arm-be

What Are Needed By a Typical ACE App?

Workbench project ACE microblocks written in Microcodes Dispatch loop that links ACE microblocks ACE core components written in C/C++ and NCL

Scripts to configure IXA

Glimpse of an ACE Configuration Script

interface 0 10.1.0.1 10.1.0.255 255.255.255.0 00:01:02:03:04:05 1 interface 1 10.2.0.1 10.2.0.255 255.255.255.0 00:01:02:03:04:06 1 interface 2 10.3.0.1 10.3.0.255 255.255.255.0 00:01:02:03:04:07 1 interface 3 10.4.0.1 10.4.0.255 255.255.255.0 00:01:02:03:04:08 1 microace ifaceInput ./ingressAce none 0 1 microace ifaceOutput ./egressAce none 1 2 microace CountMicroAce ./CountMicroAce 0 0 none -target -blockname COUNT bind static ifaceInput/default CountMicroAce bind static CountMicroAce/default ifaceOutput

The Simple Count ACE Example

Count the number of packets which are input from each port Display packet count

Compiling and Running the Count ACE App

Compiling the microcode project (Workbench)

Compiling the ACE core component (cross compiler)

Modifying the IXA configuration script Starting and running the count app By default, all binaries and scripts are copied to /opt/ixasdk/bin/arm-be To change that, you need to modify all the related Makefiles

Compile the Count Microcode Project

Copy the whole Count_8_1 project directory to some directory of your own Modify the include paths in Count_8_1.dwp
replace ..\..\ with the full path of \opt\ixasdk\src\microace, for me it is eLinuxID-IXP1200\cygwin\opt\ixasdk\src\microace. ..\..\include\IXPblocks\ ..\..\aces\interface_ace\include\ ..\..\aces\interface_ace\microblock\ ..\..\common\ ...

Build Microengine binary

Compile the Count ACE Core Component

Copy /opt/ixasdk/src/microace/aces/tutorial1/ to a different directory of your own Goto the new directory, cd to /count_ace1, then type
make

The default Makefile rule copies the result CountMicroAce to /opt/ixasdk/bin/arm-be Permission deny error if you do this on ilabx without modifying the makefile.

Modify and Copy the Count IXA Configuration Script

Goto your project directory Modify ixsys_count_8_1.config Type make to copy it to /opt/ixasdk/bin/arm-be

Run the Count ACE App

Log into one of the ilab machines Log into the BV board Goto /net/hp31/ixpdev/exportssdk2.0/opt/ixasdk/bin/arm-be Run ixstart ixsys_count_8_1.config

iLab Setup
Switch Connecting to CoC
10/100BT 10/100BT

to CoC

10/100BT

ilab1
IP over PCI

ilab2
IP over PCI

ilab8
IP over PCI

BV Board

BV Board
10/100BT

BV Board
10/100BT 10/100BT

10/100BT 10/100BT 10/100BT

Internal Switch Each BV board only has two ports connected to the internal switch. There is no gig port. The Count App must be modified in order to run on theBV board.