Partial cacheline flush problems on ARM and MIPS

[Adrian Chadd]

On 27 August 2012 08:12, Tim Kientzle <tim at kientzle.com> wrote:

>> No. I don't think so.  the reason is that you can't define USB_DMA_ALGIN to be a constant on MIPS, at least, or I think ARM because that's determined at run time.

FYI,  I wonder if MIPS may need some run time value for that. Right
now we hide it behind needing a custom config file for each mips
variant, rather than supporting one mips24k kernel for ${LOTS} of
variants.

> But don't mbuf structures do pretty much what Hans is suggesting?
>
> Why is mbuf okay?

Which part of mbufs?

I think the difference here is that there's no concurrent access. Ie,
although you may have an mbuf header + data inside the same cache
line, you wouldn't go fondling the mbuf once it's handed to the
hardware.

But I was under the impression that mbuf + mbuf buffers are already
correctly aligned.

This all honestly looks like a very i386-centric interpretation of the
busdma "intention", which I think illustrates a need to better
document what assumptions busdma actually makes.

That does remind me, I think the ath(4) driver does the same (since it
allocates its own descriptor block and then treats it as an array of
descriptors for the hardware to access) - I should ensure that
sizeof(ath_desc) is aligned on the relevant architecture. It gets
slightly scary - AR93xx TX descriptors are "L1 cache == 128 byte
aligned" which is an enormous waste of memory compared to a 16 or 32
byte aligned platform. Alas..



Adrian