Intel IXP400 manual Transmit Buffer Management and Priority

Intel® IXP400 Software

Access-Layer Components: Ethernet Access (IxEthAcc) API

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.2Transmit 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.

Programmer’s Guide	IXP400 Software Version 2.0	April 2005
	Document Number: 252539, Revision: 007	135