Intel® IXP400 Software
Access-Layer Components: Ethernet Access (IxEthAcc) API
April 2005 IXP400 Software Version 2.0 Programmer’s Guide
140 Document Number: 252539, Revision: 007
Codelet or client a pplication
IxEthAc c
IxQMgr
1.In itializations , C allback
Registration...
2. PortRxFreeReplenish (Port 0)
PortRxFreeReplenish (Port 1)
PortRxFreeReplenish (Port 2)
4. IxEthAcc will
store extra ixp_buf
pointers if IxQMgr
port-specific free
queues are full.
6. IxQmgr dispatches
IxEthAcc callb ack
function, passes ixp_buf
pointers. If Receive QoS
mode, IxEthAcc will place
pointers in appropriate
Traffic Class queues.
8. RxCallback (Port 0)
RxCallback (Port 1)
RxCallback (Port 2)
Free Enet 0
Free Enet 1
3. PortEnable (Port 0)
PortEnable (Port 1)
PortEnable (Port 2)
9. Client must free buffers,
replenish PortRxFree
queues
RxEne t
Incoming
Ethernet
Frames
7. IxEthAcc dispatches
port specific callback
functions, passes
ixp_buf pointers
B2366-04
5. NPE’s receive frames,
write receive traffic data,
muxes ixp_buf pointer
onto RxEnet queue, or
multiple RxEne t priorit y
queues, if Receive QoS
mode is enabled.
Free Enet 2
Option al Prior ity Q ueues
NPEs
Rx FIFO No Priority
Received frames from all NPEs are multiplexed onto one queue manager queue. The IxEthAcc
component will de-multiplex the received frames and call the associated user level callback
function registered via IxEthAccRxCallbackRegister(). The frames placed in the IxQMgr queue
have already been validated to have a correct FCS. They are also free from all other types of MAC/
PHY-related errors, including alignment errors and “frame too long” errors. Note that the receive
callback is issued in frame-receive order. No receive priority mechanisms are provided. Errored
frames (FCS errors, size overrun) are not passed to the user.