Intel® IXP400 Software
Buffer Management
April 2005 IXP400 Software Version 2.0 Programmer’s Guide
50 Document Number: 252539, Revision: 007
Tx Cache Flushing Example
In the case of an Ethernet bridging system, only the user can determine that it is not necessary to
flush any part of the packet payload. In a routing environment, the stack can determine that only
the beginning of the mbuf may need to be flushed (for example, if the TTL field of the IP header is
changed). Additionally, with the VxWorks OS, mbufs can be from cached memory or uncached
memory. Only the user knows which buffers need to be flushed or invalidated and which buffers do
not.
When the NPE has transmitted the data in a buffer, it will return the buffer back to the Intel XScale
core. In most cases, the cache copy is still valid because the NPE will not modify the contents of
the buffer on transmission. Therefore, as a general rule, the IXP400 software does not invalidate
the cached copy of IXP_BUF used for transmission after they are returned by the NPE.
3.7.2 Rx Path
If a buffer has been altered by an NPE, the change will exist in memory but the copy of the buffer
in Intel XScale core cache may not be up-to-date. We need to ensure that the cached copy is up-to-
date by invalidating the portion of cache that contains the copy of the altered buffer data.
The strategy for dealing with data received by the NPEs uses the following general guidelines:
•The “user” is responsible for invalidating the data section of the IXP_BUF. Again, only the
user knows which portions of the data section it needs to access. In some instances, the user
may be required to submit free IXP_BUFs that are to be used to hold received data (for
example, ixEthAccPortRxFreeReplenish()). It is strongly recommended that the cache
location holding the data portion of the free IXP_BUFs be invalidated before submitting them
via the API.
•The IXP400 software is responsible for writing and flushing the ix_ne shared section of the
buffer header. The IXP400 software may modify the header of the IXP_BUF before passing it
to the NPE, hence the need to flush and then invalidate the header section of the IXP_BUF.
This should be done before submitting an IXP_BUF to the NPE for reception (via IxQMgr
queues).
Note: In some cases, the Access-Layer will flush the header section of the IXP_BUF before submitting
the IXP_BUF to the NPE, and will invalidate the header section after receiving it back from the
NPE with data. This approach is also acceptable; however, the approach listed above is considered
more efficient and more robust.
As in the flushing operations listed in the previous section, invalidating portions of the cache is an
expensive operation in terms of CPU cycles. To minimize the performance impact of cache-
invalidating, the IXP400 software only invalidates that which it modifies (the IXP_BUF header)
and leaves the invalidating of the data section as the responsibility of the user. The user can
minimize the performance impact by invalidating only what is necessary. When recycling
IXP_BUFs, only the user knows what was the previous use of the IXP_BUF and the parts of
payload that may need to be invalidated.
3.7.3 Caching Strategy Summary
Before the NPE reads the memory, ensure that the memory is up-to-date by flushing cached copies
of any parts of the buffer memory modified by the Intel XScale core.