Intel IXP2800 2.7.3.4 Receive Operation Summary,

64 Hardware Reference Manual
Intel® IXP2800 Network Processor
Technical Description
Each RX_THREAD_FREELIST has an associated countdown timer. If the timer expires and no
new receive data is available yet, the receive logic will autopush a Null Receive Status Word to the
next thread on the RX_THREAD_FREELIST. A Null Receive Status Word has the “Null” bit set,
and does not have any data or RBUF entry associated with it.
The RX_THREAD_FREELIST timer is useful for certain applications. Its primary purpose is to
keep the receive processing pipeline (implemented as code running on the Microengines) moving
even when the line has gone idle.
It is especially useful if the pipeline is structured to handle mpackets in groups, i.e., eight mpackets
at a time. If seven mpackets are received, then the line goes idle, then the timeout will trigger the
autopush of a null Receive Status Word, filling the eighth slot and allowing the pipeline to advance.
Another example is if one valid mpacket is received before the line goes idle for a long period;
seven null Receive Status Words will be autopushed, allowing the pipeline to proceed. Typically
the timeout interval is programmed to be slightly larger than the minimum arrival time of the
incoming cells or packets.
The timer is controlled using the RX_THREAD_FREELIST_TIMEOUT_# CSR. The timer may
be enabled or disabled, and the timeout value specified using this CSR.
2.7.3.4 Receive Operation Summary
During receive processing, received CFrames, and SPI-4 cells and packets (which in this context
are all called mpackets) are placed into the RBUF, and then handed off to a Microengine to process.
Normally, by application design, some number of Microengine Contexts will be assigned to
receive processing. Those Contexts will have their number added to the proper
RX_THREAD_FREELIST (via msf[write]or msf[fast_write]), and then will go to sleep to
wait for arrival of an mpacket (or alternatively poll waiting for arrival of an mpacket).
When an mpacket arrives, MSF receive control logic will autopush eight bytes of information for
the element to the Microengine/CONTEXT/S_TRANSFER registers at the head of
RX_THREAD_FREELIST. The information pushed is:
•Status Word (SPI-4) or Header Status (CSIX) — see Table90, “RBUF SPIF-4 Status
Definition” on page 252 for more information.
•Checksum (SPI-4) or Extension Header (CSIX) — see Table91, “RBUF CSIX Status
Definition” on page 254 for more information.
To handle the case where the receive Contexts temporarily fall behind and
RX_THREAD_FREELIST is empty, all received element numbers are held in the
FULL_ELEMENT_LIST. In that case, as soon as an RX_THREAD_FREELIST entry is entered,
the status of the head element of FULL_ELEMENT_LIST will be pushed to it.
The Microengines may read part of (or the entire) RBUF element to their S_TRANSFER registers
(via an msf[read] instruction) for header processing, etc., and may also move the element data to
DRAM (via a dram[rbuf_rd] instruction).
When a Context is done with an element, it does an msf[write]or msf[fast_write] to
RBUF_ELEMENT_DONE address; the write data is the element number. This marks the element
as free and available to be re-used. There is no restriction on the order in which elements are freed;
Contexts can do different amounts of processing per element based on the contents of the element
— therefore elements can be returned in a different order than they were handed to Contexts.