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 139
9.5.3.2 Receive Buffer Management and Priority
The key interface from the NPEs to the receive data path (IxEthAcc) is a selection of queues
residing in the queue manager hardware component. These queues are shown in Figure 52.
Buffer Sizing
The receive data plane subcomponent must provide receive buffers to the NPEs. These
IX_OSAL_MBUFs should be sized appropriately to ensure optimal performance of the Ethernet
receive subsystem. The IX_OSAL_MBUF should contain IX_ETHACC_RX_MBUF_MIN_SIZE
bytes in a single data cluster, though chained IX_OSAL_MBUFs are also supported. It is expected
that chained IX_OSAL_MBUFs will be used to handle large frames. Receive frames may be
pushed into a chained IX_OSAL_MBUF structure, but excessive chaining will have an adverse
impact upon performance.
The NPEs write data in 64 byte words. For maximum performance, the IX_OSAL_MBUF size
should be greater than the maximum frame size (Ethernet header, payload and FCS), rounded up to
the next 64 byte multiple. Supplying smaller IX_OSAL_MBUFs to the service results in
IX_OSAL_MBUF chaining and degraded performances.
The minimum buffer size for IEEE 802.3 Ethernet frame traffic without VLAN or IPSEC features
should be 1536 bytes (1518 byte Ethernet frame + 18 bytes for 64 byte alignment). For IEEE 802.3
traffic, the recommended size is 2,048 bytes. This is adequate to support VLAN-tagged Ethernet
802.3 frames, IPSec encapsulated Ethernet frames, “baby jumbo” frames without chaining, and
“jumbo” frames with chaining. The maximum 802.11 frame size is 2348 bytes. Therefore, if the
802.3 <-> 802.11 Frame Conversion feature will be used, the IX_OSAL_MBUF should be sized at
2368 bytes (2348 + 20 for 64 byte alignment) or larger.
Buffers may not be filled up to their length. The NPE microcode will fill the IX_OSAL_MBUF
fields up to the 64-byte boundary. The user should to be aware that the length of the received
IX_OSAL_MBUFs may be smaller than the length of the supplied IX_OSAL_MBUFs.
Supplying Buffers
There are three separate free buffer IxQMgr queues allocated to providing the NPEs with receive
buffers (one per port). The buffers are supplied on a per port basis via the user level interface
ixEthAccPortRxFreeReplenish() function. The replenish function loads the port specific free buffer
IxQMgr queue with an IX_OSAL_MBUF pointer. The replenish function can provide checking to
ensure that the IX_OSAL_MBUF is at least as large as IX_ETHACC_RX_IXP_BUF_MIN_SIZE.
If the port specific free buffer IxQMgr queue is full, the replenish function queues the buffer in a
software queue. Once a low threshold on the specific queue is reached the software reloads the port
specific free buffer queue from its software queue if available. Frames greater in size than the size
of the IX_OSAL_MBUF provided by the replenish function will trigger chaining.
Note: The ixEthAccPortRxFreeReplenish() function can receive chained IX_OSAL_MBUFs, which the
NPEs will be able to unchain as needed. This method may offer a performance improvement for
some usage scenarios.
The user also must ensure that there are sufficient buffers assigned to this component to maintain
wire-speed, Ethernet-receive performance. If the receive NPE does not have a receive buffer in
advance of receiving an Ethernet frame, the frame will be dropped. Should a frame arrive while
there are no free buffers is available, no callback indication will be provided and a
rx_buffer_underrun counter will be incremented.