On Tue, Jan 10, 2012 at 01:52:49PM -0800, Adrian Chadd wrote: > On 10 January 2012 13:37, Luigi Rizzo <rizzo_at_iet.unipi.it> wrote: > > I was glancing through manpages and implementations of bus_dma(9) > > and i am a bit unclear on what this API (in particular, bus_dmamap_sync() ) > > does in terms of memory barriers. > > > > I see that the x86/amd64 and ia64 code only does the bounce buffers. > > The mips seems to do some coherency-related calls. > > > > How do we guarantee, say, that a recently built packet is > > to memory before issuing the tx command to the NIC ? > > The drivers should be good examples of doing the right thing. You just > do pre-map and post-map calls as appropriate. > > Some devices don't bother with this on register accesses and this is a > bug. (eg, ath/ath_hal.) Others (eg iwn) do explicit flushes where > needed. so you are saying that drivers are correct unless they are buggy :) Anyways... i see that some drivers use wmb() and rmb() and redefine their own version, usually based on lfence/sfence even on i386 #define rmb() __asm volatile("lfence" ::: "memory") #define wmb() __asm volatile("sfence" ::: "memory") whereas the standard definitions are slightly different, e.g. sys/i386/include/atomic.h: #define rmb() __asm __volatile("lock; addl $0,(%%esp)" : : : "memory") #define wmb() __asm __volatile("lock; addl $0,(%%esp)" : : : "memory") and our bus_space API in sys/x86/include/bus.h is a bit unclear to me (other than the fact that having 4 unused arguments don't really encourage its use...) static __inline void bus_space_barrier(bus_space_tag_t tag __unused, bus_space_handle_t bsh __unused, bus_size_t offset __unused, bus_size_t len __unused, int flags) { #ifdef __GNUCLIKE_ASM if (flags & BUS_SPACE_BARRIER_READ) #ifdef __amd64__ __asm __volatile("lock; addl $0,0(%%rsp)" : : : "memory"); #else __asm __volatile("lock; addl $0,0(%%esp)" : : : "memory"); #endif else __asm __volatile("" : : : "memory"); #endif } cheers luigiReceived on Tue Jan 10 2012 - 21:24:01 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:23 UTC