[Top] [All Lists]

Re: [PATCH] include/asm-mips/pci.h: More optimal cache behavior, added "

To: William Jhun <>
Subject: Re: [PATCH] include/asm-mips/pci.h: More optimal cache behavior, added "prep" routines
From: Jun Sun <>
Date: Tue, 28 May 2002 09:49:47 -0700
References: <> <>
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv: Gecko/20010901
William Jhun wrote:

On Sat, May 25, 2002 at 01:18:06PM -0700, William Jhun wrote:

When preparing a buffer for a DMA transfer, we've found it's more
optimal to only do a wback_inv if the direction is not known
(PCIDMA_BIDIRECTIONAL), only a wback if transfer is to the device
(PCIDMA_TO_DEVICE), and only an invalidate if from the device
(PCIDMA_FROM_DEVICE). Such a modification has made a small (yet
significant) improvement for one of our network drivers during a packet
forwarding rate test.

*sigh*. On the platform we were testing on, we used our own cache code
(rm7k with tertiary cache support) which has been well-tested for over a
year now. In these routines, we implement dma_cache_wback and only do
invalidates (no flush) for dma_cache_wback_inv. Now that I'm looking
around in cache support for other MIPS CPUs, I see that all the _wback
calls are not implemented and that many (or all?) of the _inv calls also
flush the caches.

The patch below leaves the existing funtions alone and just adds the two
pci_dma_prep_{sg,single}() calls.

My question is: why are these dma_cache_wback calls not implemented? And
how come dma_cache_inv is treated the same as dma_cache_wback_inv? Are
we doing something wrong by implementing these calls in our cache code
as they are described?

In theory cache_wback and cache_inv are doing different things. In practice, however, since the call must be made *before* dma transfer starts so the effects are same. Of course, _inv() version is more efficient if it is implemented.


<Prev in Thread] Current Thread [Next in Thread>