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