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

More documents

Recommendations

Info

The Object Management System A networking application that uses the ACE programming framework makes use of function libraries, macros, and so on that are provided with the SDK. Such an application includes source code in the following languages: Language Tools Libraries and predefined code C/C++ Gnu toolchain (gcc, ld, gdb, and so on) Object Management System (OMS), Action Services Library (ASL), Resource Manager, startup and configuration scripts IXP1200 microcode IXP1200 Microengine Development Environment IXP1200 packet-handling macros, microACE macros Network Classification Language (NCL) IXA Interface Definition Language (IDL) NCL compiler (nclcomp) IXA IDL compiler (tao_idl) TCP/IP protocol definitions The IXA SDK provides entire predefined ACEs that you can use as building blocks for rapid application development. These include the following: l l l The interface ACEs, system-defined microACEs that every application uses to receive and transmit packets on the network interface ports The stack ACE, which represents the Linux * TCP/IP stack Several library ACEs that perform typical networking tasks such as layer-three packet forwarding, layer-two bridging, and network address translation. For more information on the predefined ACEs, see Chapter 7, “Interface ACEs,” and Chapter 8, “Stack and Library ACEs.” The Object Management System The Object Management System (OMS), part of the IX system software, is a single logical entity with components distributed throughout the system. The OMS services are part of the IXA API. The management and control modules for an application use the global C functions defined by the OMS services to create, configure, control, and destroy objects and structures in all parts of the application, and to perform global tasks. The primary global services your application requires are: l l l Creating and destroying ACEs Defining and controlling packet flow using targets Communicating among ACEs and other programs with crosscalls Parts of the OMS The OMS contains the following parts: l The Resolver, which creates and deletes ACEs, and manages packet flow by binding ACEs and targets. 20 Elements of an Application Revision 3.3, August 2001
The Object Management System l The Name Server, which manages the name space for the OMS, maintaining a correspondence between names and internal identifiers for ACEs, targets and so on. The name space allows objects that might be distributed among processors to address one another unambiguously. The OMS also defines some general global functions to coordinate interobject communication through crosscalls. You typically set up both the development and delivery environments to start the OMS automatically on boot, so that it is always running. Accessing the OMS In order to communicate with the OMS, an object or program must create a communications channel in the form of a separate process or thread called a communication access process, or CAP. l l When you create an ACE, the initialization procedure automatically creates the CAP, and the ACE runtime polls that CAP for crosscall events in its main loop. You can access the CAP with the function ix_ace_to_cap. If your application contains other programs that need to communicate with the OMS (a manager program, for example), each such object must register with the OMS as a task. The task, like an ACE, contains a CAP, which you can access with the function ix_task_to_cap. The task’s main loop must poll for crosscall events on the CAP channel. Before you can create an ACE or task, you must create a CAP with which to make the Resolver calls. To create a CAP, use the ASL function ix_cap_init. Any application that needs to communicate with the OMS must include the ASL core services library, as well as the OMS services library, even if it does not use any ASL functions other than ix_cap_init. Naming Objects The Name Server provides a name space, which allows objects that might be distributed among processors to address one another unambiguously. The Name Server supports a hierarchical UNIX-like directory structure. The name of a target (for example) needs to be unique only within an ACE, and the name of the ACE needs to be unique only within an application-defined directory. To completely and uniquely identify an entity to the Name Server, you must use the full name, or complete path to the entity. You use the full name whenever you refer to an object using the OMS services. For example, a call to ix_res_bind must specify the full name of both the target and the ACE. For example, to create a binding between the default target in an ACE named MyAce and an ACE named ControlAce, in an application with no other name space directories defined, use the following full names in the ix_res_bind method: ix_res_bind (ressession, "/MyAce/default" , "/ControlAce"); For More Information l For more information on targets and bindings, see Chapter 5, “Controlling Packet Flow.” Revision 3.3, August 2001 Elements of an Application 21
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 and 20: 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: Chapter 2 Elements of an Applicatio
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 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 ...

Create successful ePaper yourself

Delete template?

Save as template?