Filter
Top Products
Intel
®
IXP400 Software
Buffer Management
Programmer’s Guide IXP400 Software Version 2.0 April 2005
Document Number: 252539, Revision: 007 49
3.7 Caching Strategy
The general caching strategy in the IXP400 software architecture is that the software (include Intel
XScale core-based code and NPE microcode) only concerns itself with the parts of a buffer which
it modifies. For all other parts of the buffer, the user (higher-level software) is entirely responsible.
IXP_BUF buffers typically contain a header section and a data section. The header section contains
fields that can be used and modified by the IXP400 software and the NPEs. Examples of such
fields are:
• pointer to the data section of the IXP_BUF
• length of the data section of the mbuf
• pointer to the next mbuf in a chain of mbufs
• buffer type field
• buffer flags field
As a general rule, IXP400 software concerns itself only with IXP_BUF headers, and assumes that
the user (that is, higher-level software) will handle the data section of buffer.
The use of cached memory for IXP_BUF buffer is strongly encouraged, as it will result in a
performance gain as the buffer data is accessed many times up through the higher layers of the
operating system’s network stack. However, use of cached memory has some implications that
need to be considered when used for buffers passed through the IXP400 software Access-Layer.
The code that executes on Intel XScale core accesses the buffer memory via the cache in the Intel
XScale core MMU. However, the NPEs bypass the cache and access this external SDRAM
memory directly. This has different implications for buffers transmitted from Intel XScale core to
NPE (Tx path), and for buffers received from NPE to Intel XScale core (Rx path).
3.7.1 Tx Path
If a buffer in cached memory has been altered by Intel XScale core code, the change will exist in
the cached copy of the IXP_BUF, but may not be written to memory yet. In order to ensure that the
memory is up-to-date, the portion of cache containing the altered data must be flushed.
The cache flushing strategy uses the following general guidelines:
• The “user” is responsible for flushing the data section of the IXP_BUF. Only those portions of
the data section which have been altered by the Intel XScale core code need to be flushed. This
must be done before submitting an IXP_BUF to the IXP400 software for transmission via the
component APIs (for example, ixEthAccPortTxFrameSubmit().
• The IXP400 software is responsible for writing and flushing the ix_ne shared section of the
buffer header. This must be done before submitting an IXP_BUF to the NPE. Communication
to the NPEs is generally performed by access-layer components by sending IXP_BUF headers
through the IxQMgr queues.
Since flushing portions of the cache is an expensive operation in terms of CPU cycles, it is not
advisable to simply flush both the header and data sections of each IXP_BUF. To minimize the
performance impact of cache-flushing, the IXP400 software only flushes that which it modifies
(the IXP_BUF header) and leaves the flushing of the data section as the responsibility of the user.
The user can minimize the performance impact by flushing only what it needs to.