Filter
Top Products
Intel
®
IXP400 Software
Access-Layer Components: Ethernet Access (IxEthAcc) API
Programmer’s Guide IXP400 Software Version 2.0 April 2005
Document Number: 252539, Revision: 007 135
3. Register a callback function for the port. This function will be called when the transmission
buffer is placed in the TxDone queue.
4. After configuring the port, the transmitting port must be enabled in order for traffic to flow.
5. Submit the frame, setting the appropriate priority. This places the IX_OSAL_MBUF on the
transmit queue for that port.
6. IxEthAcc transmits the frame on the wire. When transmission is complete, the
IX_OSAL_MBUF is placed in the TxDone queue.
7. Frame transmission is complete when the TxDone callback function is invoked. The callback
function is passed a pointer to that IX_OSAL_MBUF.
The frame-transmission API is asynchronous in nature. Because the transmit frame request queues
the frame for transmission at a later point, the call is non-blocking. There is no direct status
indication as to whether the frame was successfully transmitted on the wire or not. Statistics,
however, are maintained at the MAC level for failed transmit attempts.
9.5.2.2 Transmit Buffer Management and Priority
The overall queuing topology for the Ethernet transmission system is made up of the following
queues:
• Software queues within IxEthAcc for buffering traffic when downstream queues are full, or for
establishing priority queuing.
• IxQMgr queues for passing data to and from the NPEs. A maximum of 128 entries per port are
supported for the TxEnet queues, and there is a single 128 entry queue for TxEnetDone.
• NPE microcode queues, used to hold IX_OSAL_MBUF header data for transmission. There
are 64 entries in the NPE microcode queue(s).
Figure 50 provides a visual explanation of queue management for Ethernet transmission.
The IxQMgr queues are a maximum of 128 entries deep per port. The frame submit function must
internally queue (in the IxEthAcc software) frames which are submitted in excess of a predefined
limit. All internally queued buffers submitted for transmission but not queued to the hardware
queues are stored in IxEthAcc software queues. If priority FIFO queuing is being used, the frames
will be saved in individual per priority FIFOs.
Frames will be submitted to the port specific IxQMgr queue when a low/empty threshold is
reached on the queue. From there, the buffer header is passed into the NPE queue that supports that
respective port. If priority queueing is enabled, the NPE can re-order the frames internally to
ensure that higher priority frames are transmitted before lower priority frames.
Once frame transmission has completed, the buffer is placed on the TxEnetDone IxQMgr queue.
This queue contains multiplexed entries from both NPE ports. The IxEthAcc software consumes
entries from this queue and returns the buffers to the client via the function previously registered by
IxEthAccTxDoneCallbackRegister( ).
There is no specific port flush capability. To retrieve submitted buffers from the system, the port
must be disabled, using the IxEthAccPortDisable() function. This has the result of returning all Tx
buffers to the TxDone queue and then passed to the user via the registered TxDone callback.