Source-Changes archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: CVS commit: src/sys/dev/ic



On Sun, Oct 29, 2006 at 06:57:16AM -0800, Jason Thorpe wrote:
> 
> On Oct 29, 2006, at 1:49 AM, David Young wrote:
> 
> >You must pad struct rtk_desc to the cacheline size to avoid cacheline
> >interference.  I cannot emphasize enough how important that is!
> 
> That only works for devices which provide a "next descriptor" address  
> in the descriptor itself.  Not all devices do (they assume a packed  
> ring, or something).
> 
> That said...

There are also chips that let us write a register to set the descriptor
size to whatever we like.

For all other chips, we either need for the platform to ensure DMA
coherency, or else we need to arrange exclusive host/device access to
every N descriptors, where (N * sizeof(descriptor)) % sizeof(cacheline)
== 0, or else something else....

> >bus_dma really ought to provide a #define for the machine's cacheline
> >size.
> 
> ...yes, bus_dma really should provide a function that returns this  
> value.

Suppose I add #define bus_dma_cacheline(__tag) in an MI header, setting it
to some Suitably Large number (128? 256?), and then let MD code override?
E.g., MI:

        #define bus_dma_cacheline(__tag)        ((bus_size_t)256)

MD:

        static inline bus_size_t
        _myarch_bus_dma_cacheline(bus_dma_tag_t tag)
        {
                /* ... */
        }
        #undef bus_dma_cacheline
        #define bus_dma_cacheline       _myarch_bus_dma_cacheline

On coherent architectures such as x86, should bus_dma_cacheline()
yield the actual cacheline size, or 1?  If 1, what should the name of
the function be?

Dave

-- 
David Young             OJC Technologies
dyoung%ojctech.com@localhost      Urbana, IL * (217) 278-3933



Home | Main Index | Thread Index | Old Index