Filter
Top Products
Intel
®
IXP400 Software
Access-Layer Components: ATM Driver Access (IxAtmdAcc) API
Programmer’s Guide IXP400 Software Version 2.0 April 2005
Document Number: 252539, Revision: 007 57
• Check for ATM VC already in use in an other Rx connection.
• Check if the service type is OAM and, if so, check that the VC is the dedicated OAM-VC.
• Register the callback by which received buffers get pushed into the client’s protocol stack.
• Register the notification callback by which the hardware will ask for more available buffers.
• Allocate a connection ID and return it to the client.
When connecting, a connection ID is allocated and must be used to identify the VC, in all calls to
the API. The connection IDs for Receive and Transmit, on the same ATM VC, are different.
The client has the choice of using a threshold mechanism provided by IxAtmdAcc or polling the
different resources. When using the threshold mechanism, the client needs to register a callback
function and supply a threshold level. As a general rule, when configuring threshold values for
different services, the lower the threshold value is, the higher the interrupt rate will be.
4.5 Transmission Services
The IxAtmdAcc transmit service currently supports AAL 5, AAL 0-48, AAL 0-52, and OAM only
and operates in scheduled mode.
In scheduled mode, buffers are accepted and internally queued in IxAtmdAcc until they are
scheduled for transmission by a scheduling entity. The scheduling entity determines the number
cells to be transmitted from a buffer at a time, this allows cells from different VCs to be interleaved
on the wire.
AtmdAcc accepts outbound ATM payload data for a particular VC from its client in the form of
chained IXP_BUFs. For AAL 5, an IXP_BUF chain represents an AAL-5 PDU which can contain
0-65,535 payload octets. A PDU is, however, a multiple of 48 octets, when padding and the AAL-5
trailer are included. For AAL 0-48/AAL 0-52/OAM, an IXP_BUF chain represents a PDU where
the maximum length is limited to 256 chained IXP_BUFs and/or 65,535 octets.
The submission rate of buffers for transmission should be based on the traffic contract for the
particular VC and is not known to IxAtmdAcc. However, there will be a maximum number of
buffers that IxAtmdAcc can hold at a time and a maximum number of buffers that the underlying
hardware can hold — before and during transmission. This maximum is guaranteed to facilitate the
port rate saturation at 64-byte packets.
Under the ATM Scheduler control (scheduled mode), IxAtmdAcc interprets the schedule table and
builds and sends requests to the underlying hardware. For AAL 5/AAL 0-48, these will be
segmented into 48-byte cell payloads and transmitted with ATM cell headers over the UTOPIA
bus. For AAL 0-52/OAM, these cells will be segmented into 52-byte cells, HEC added, and they
will be transmitted “as is” over the UTOPIA bus.
Once the transmission is complete, IxAtmdAcc passes back the IXP_BUFs to its client (on a per-
connection basis). The client can free them or return them to the pool of buffers. The preferred
option is to reuse the buffers during the next transmission. Processing of transmit-done buffers
from IxAtmdAcc is controlled by the client.
Transmit Done is a system-wide entity which provides a service to multiple ports. A system using
multiple ports — with very different transmit activity — results in latency effects for low-activity
ports. The user needs to tune the number of buffers — needed to service a low-rate port or channel