>>>>> "Philip" == Philip Blundell <[EMAIL PROTECTED]> writes:
>> This doesnt help you in general. Having the ring buffer uncached
>> on a lance is the wrong solution (tm) for most platforms. Its
>> better to flush the page out of cache and push it to memory when
>> writing. That gets you things like burst writes.
Philip> The idea for cached memory was for descriptor lists and
Philip> things that you touch frequently but usually only a single
Philip> word at a time. For those it seems better to have an
Philip> uncached area than push it out of the cache all the time.
Philip> Burst writes aren't a big deal if you're only transferring
Philip> one word, and a single-word uncached read is actually faster
Philip> than a cache line fill.
Philip> For packet buffers and the like I agree with you.
I'll second that.
I spend my days writing code for a MIPS-based router. As Philip
mentioned earlier, MIPS systems certainly tend to avoid snoopy DMA
designs, and a 68040 I worked on likewise. The reason for that is
simple: DMA coherence at best gives you a MAJOR complexity hit in the
hardware design, and at worst a major performance hit as well. (For
example the 68040 supported it but at the cost of a clock tick per DMA
cycle, not to mention the need to couple the processor bus much more
closely to the other buses in the system.)
For routers, it turns out the best design is to have all I/O related
memory (packet buffers too) uncached. Sometimes if you don't mind the
software hair it helps a little to access a header or descriptor via a
cached alias address but this is very hard to get right.
For a general purpose system I'd agree that the packet buffers
*probably* should be cacheable -- especially if the CPU in question
can do cache push efficiently. (The 68040 is an example of one that
cannot -- a null cache push takes 256 cycles!) But all I/O control
structures such as device descriptor rings or queues are best put in
uncached space; the performance impact is somewhere between trivial
and nil for this sort of system, and the benefits in software
reliability are large indeed.
paul
unsubscribe: body of `unsubscribe linux-arm' to [EMAIL PROTECTED]
