Intel IXA SDK ACE Programming Framework - Department of ...

More documents

Recommendations

Info

The ACE Programming Framework for Packet Handling An ACE is defined by several distinct source code files. An initialization part, which creates and initializes needed structures and variables, and the action part, which defines the associated action functions, are written in C/C++. The classification part of the ACE, which defines a set of packet classification rules, is written in Network Classification Language (NCL ) Each ACE generally performs one type of packet handling or data control task. You can distribute tasks among ACEs, and ACEs among code modules in any way that is logical for your application. The following figure shows the high-level architecture of a typical IXA application. Managing application Object creation, flow control Error handling, status ACE Control module ACE Data management Data initialization, configuration Exception cases Input interface Output interface Packet flow ACE ACE Data processing modules You can create your own ACEs using the IXA API, or you can use predefined ACEs that perform specific network processing tasks, as described below in “Predefined ACEs.” Your application defines the flow of packets among ACEs by creating packet destinations called targets and by binding the targets to other ACEs; see “Defining the Traffic Flow Path with Targets” on page 11. Writing ACEs using C, NCL and IXA IDL In the initialization part of an ACE, you create the ACE structure itself, with its related communication methods and data structures, using the ASL core C library. In the classification part of an ACE, rules can compare packet contents against static values or against dynamic data. You define these rules using the Network Classification Language (NCL) provided with the IXA SDK. NCL is a domain-specific objectoriented language for defining packet classification rules and identifying the associated actions to be taken when matches occur. This language-based approach makes it easy for you to specify the required classification criteria. 6 Introduction and Overview Revision 3.3, August 2001
The ACE Programming Framework for Packet Handling In the action part of an ACE, you define the ACE infrastructure and action functions in C/C++. In the action functions, you can use run-time support for networking tasks provided by the ASL application services. These C/C++ class and function libraries provide support for handling application-specific operations; for example, TCP/IP operations such as IP fragmentation and reassembly, Network Address Translation (NAT), and TCP connection monitoring and stream reconstruction. For communication between ACEs and other parts of an application, you define remote function calls, using an interface definition language, IXA IDL. This compiles to C and becomes part of the ACE’s C source code. See “Communication Among ACEs” on page 12. Predefined ACEs Depending on who develops it and how it is created, an ACE can be a user ACE, a library ACE, or a system ACE. You can combine all three types in an application. l l User ACEs User ACEs are those that you develop yourself, defining all of the classification rules and actions. Library ACEs Intel supplies a set of predefined library ACEs, which provide building blocks for common application functionality such as layer 2 bridging and layer 3 (IP) forwarding. NOTE: Some library ACEs are supplied with source code so that you can configure them and modify their packet classification criteria and actions. When you modify a library ACE, it becomes a user ACE and is no longer supported and maintained by Intel. l System ACEs These platform-specific ACEs represent hardware network interfaces (interface ACEs) or protocol stacks (stack ACEs). The system ACEs are not necessarily implemented like other ACEs; they simply mask hardware and system details that are specific to a particular environment, and look like ACEs to your application. The system ACEs act as packet sources and destinations. They are opaque to other ACEs. You can configure system ACEs and communicate with them, but you cannot modify them. You customize the system initialization scripts to load and start the system ACEs your application and hardware configuration requires. The IXA SDK supplies system ACEs for the Ethernet * 10/100 and gigabit ports on the IXDP1200 Advanced Development Platform, and for the Linux TCP/IP stack. Accelerated ACEs The ACE architecture allows an ACE to take advantage of the speed of dedicated processors. An ACE that runs entirely on the core processor is a conventional ACE. An ACE that includes code for another processor is called an accelerated ACE. The IXA SDK provides a type of accelerated ACE called a microACE. The microACE programming model provides a framework for creating a packet-processing application that makes use of the IXP1200’s microengines. A microACE has two logical components, running on different processors: Introduction and Overview 7 Revision 3.3, August 2001
Page 1 and 2: Intel ® IXA SDK ACE Programming Fr
Page 3 and 4: Contents About This Guide. . . . .
Page 5 and 6: L2 Bridging Configuration File . .
Page 7 and 8: ICMP Error Packet Handling . . . .
Page 9 and 10: About This Guide This guide introdu
Page 11 and 12: Other Sources of Information Other
Page 13 and 14: Contacting Intel http://support.int
Page 15 and 16: Chapter 1 Introduction and Overview
Page 17 and 18: Logical Elements of an IXA Applicat
Page 19: The ACE Programming Framework for P
Page 23 and 24: The ACE Programming Framework for P
Page 25 and 26: OMS for Global Application Services
Page 27 and 28: OMS for Global Application Services
Page 29 and 30: Hardware Architecture: The IXP1200
Page 31 and 32: Components of the IXA SDK for the I
Page 33 and 34: Chapter 2 Elements of an Applicatio
Page 35 and 36: The Object Management System l The
Page 37 and 38: ACEs and Support Structures To crea
Page 39 and 40: The Application Building Process Th
Page 41 and 42: The Application Building Process c.
Page 43 and 44: Chapter 3 Compiling and Testing App
Page 45 and 46: Overview of the ACE Compilation and
Page 47 and 48: Using Makefiles l The microengine t
Page 49 and 50: Chapter 4 Configuring and Starting
Page 51 and 52: The System Configuration File Start
Page 53 and 54: Setting Up Particular Configuration
Page 61 and 62: Chapter 5 Controlling Packet Flow T
Page 63 and 64: Binding Targets as Packet Destinati
Page 65 and 66: Directing Packets to a Target //all
Page 67 and 68: Receiving and Transmitting on Netwo
Page 69 and 70: Chapter 6 Writing MicroACEs This ch
Page 71 and 72:
MicroACE Architectural Elements Arc
Page 73 and 74:
Loading MicroACEs 8. Start the micr
Page 75 and 76:
Writing the Core Component of a Mic
Page 77 and 78:
Page 79 and 80:
Page 81 and 82:
Page 83 and 84:
Microblock Types and Groups You wri
Page 85 and 86:
Writing a Dispatch Loop Block Type
Page 87 and 88:
Writing a Dispatch Loop Defining Ad
Page 89 and 90:
Writing a Microblock DL_SASink#: DL
Page 91 and 92:
MicroACE Design Example .elif (dl_n
Page 93 and 94:
Chapter 7 Interface ACEs This chapt
Page 95 and 96:
Initializing Interface ACEs A compl
Page 97 and 98:
The Input ACE The Input ACE The inp
Page 99 and 100:
The Output ACE l l l l l l Initiali
Page 101 and 102:
Chapter 8 Stack and Library ACEs Th
Page 103 and 104:
The L3 Forwarder Library ACE You ca
Page 105 and 106:
The L2 Bridging Library ACE The L3
Page 107 and 108:
The L2 Bridging Library ACE Conditi
Page 109 and 110:
The NAT Library ACEs — IP masquer
Page 111 and 112:
The NAT Library ACEs ace natc ./nat
Page 113 and 114:
Chapter 9 Classifying Packets Using
Page 115 and 116:
Defining Rules as “the set of all
Page 117 and 118:
How Rules Are Evaluated protocol et
Page 119 and 120:
Chapter 10 Initializing and Acting
Page 121 and 122:
Initializing the ACE Your ACE also
Page 123 and 124:
Defining Action and Utility Functio
Page 125 and 126:
What Action Functions Do Table 1: (
Page 127 and 128:
Chapter 11 Communication Within an
Page 129 and 130:
Overview Each call client or server
Page 131 and 132:
Defining Crosscall Interfaces Use t
Page 133 and 134:
Defining Call Operations Operation
Page 135 and 136:
Invocation Types for Operations l l
Page 137 and 138:
Integrating Crosscalls with Applica
Page 139 and 140:
Initializing and Terminating Interf
Page 141 and 142:
Page 143 and 144:
Page 145 and 146:
Invoking Crosscall Functions ix_err
Page 147 and 148:
Passing Crosscall Arguments } sleep
Page 149 and 150:
Passing Crosscall Arguments — For
Page 151 and 152:
Passing Crosscall Arguments 3. Call
Page 153 and 154:
Chapter 12 Crosscall Example This c
Page 155 and 156:
Example Interface Definition /* Dec
Page 157 and 158:
Example Interface Definition /*****
Page 159 and 160:
Writing the Crosscall Client static
Page 161 and 162:
Writing the Crosscall Client } goto
Page 163 and 164:
Writing the Crosscall Client err =
Page 165 and 166:
Writing the Crosscall Client err_la
Page 167 and 168:
Writing the Crosscall Server This e
Page 169 and 170:
Writing the Crosscall Server } if(r
Page 171 and 172:
Writing the Crosscall Server } /***
Page 173 and 174:
Writing the Crosscall Server // ACE
Page 175 and 176:
Chapter 13 Using Sets of Data to Cl
Page 177 and 178:
Defining Sets and Searches You can
Page 179 and 180:
Initializing and Populating Sets ix
Page 181 and 182:
How to Use Sets and Searches err =
Page 183 and 184:
Index A ACE 5 accelerated 7 action
Page 185 and 186:
D data processing plane 3 data sets
Page 187 and 188:
NAT library ACEs 94 binding targets
Page 189 and 190:
full names of 21 L3 forwarder ACE 9
Page 191 and 192:
Revision 3.3, August 2001 177
show all

Intel IXA SDK ACE Programming Framework - Department of ...

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?