talk gatech ixp 2002

8/6/2019 Talk Gatech Ixp 2002

1/30

Software Architecture for Network Processor

Intel IXA Programming Framework

Weidong Shi

Georgia Institute of Technology 2002


2/30

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


3/30

Trends of Network Processing Hardware

Demand a software architecture that provides

programming functionality in both fast-path and slow path

initializing & configuring fast-path functionality and exception handling

Rajiv Khemani. Interfaces and Interoperability. Intel Corporation


4/30

Slow and Fast Path Protocols Inside a Network

Processor

http://www.intel.com


5/30

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


6/30

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.


7/30

Another View of IXA

Rajiv Khemani. Interfaces and Interoperability. Intel Corporation


8/30

ACE, the Building Block of IXA

Active Computing Element

It is called Action Classification

Engine in 2000

Software component for processing

packetclassifies the packets

manipulates the classified packets

Service building blocksACEs can be chained to provision a

service

each ACE perform distinct steps of

the services


9/30

Packet Flow

Target of upstream ACEs are bound to downstream ACEs.

Packet flows from an upstream ACE to a downstream ACE.

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


10/30

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).

Type of ACEs

ACEs implemented in Microcode are called MicroACEs.

MicroACEs hide the underlying hardware details from other ACEs.


11/30

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()"


12/30

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

It is slow, not recommended

for transferring packet data.

Object Management System



13/30

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 doclassification/action

Apps or other ACEs communicate with a ACE via the core

component


14/30

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.


15/30


16/30

Dispatch Loop

dl_buffer_handle handle for the current packet

dl_next_blockdestination 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

Each microblock sets two global registers


17/30

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/


18/30

Stack ACE


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.


19/30

IXA SDK Installation


20/30


21/30

Run IXA On the ilab BV Boards

All the IXA binaries, IXA scripts, and ACE binaries arestored 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


22/30

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


23/30

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 1interface 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 1microace ifaceOutput ./egressAce none 1 2

microace CountMicroAce ./CountMicroAce 0 0 none -target -blocknameCOUNT

bind static ifaceInput/default CountMicroAce

bind static CountMicroAce/default ifaceOutput


24/30

The Simple Count ACE Example

Count the number of packets which are input from each port

Display packet count


25/30

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


26/30

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 iseLinuxID-IXP1200\cygwin\opt\ixasdk\src\microace.

..\..\include\IXPblocks\

..\..\aces\interface_ace\include\

..\..\aces\interface_ace\microblock\

..\..\common\

...

Build Microengine binary


27/30

Compile the Count ACE Core Component

Copy /opt/ixasdk/src/microace/aces/tutorial1/ to a differentdirectory 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.


28/30

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


29/30

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

to CoC


30/30

iLab Setup

Switch Connecting to CoC

Internal Switch

ilab1

BV Board

IP over PCI

ilab2

BV Board

IP over PCI

ilab8

BV Board

IP over PCI

to CoC

10/100BT

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

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

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

talk gatech ixp 2002

Documents