Date: Thu, 20 Feb 2003 09:08:36 -0800 From: "Sam Leffler" <sam@errno.com> To: "Andrew Gallatin" <gallatin@cs.duke.edu> Cc: "Mike Silbersack" <silby@silby.com>, "Scott Long" <scott_long@btc.adaptec.com>, <src-committers@FreeBSD.org>, <cvs-src@FreeBSD.org>, <cvs-all@FreeBSD.org> Subject: Re: cvs commit: src/sys/dev/aac aac.c aac_pci.c Message-ID: <0e1b01c2d902$b507e270$52557f42@errno.com> References: <200302192158.h1JLwYJn025529@repoman.freebsd.org><20030219161458.T62705@patrocles.silby.com><20030219181629.A46948@grasshopper.cs.duke.edu><20030219182122.N62705@patrocles.silby.com><3E54219C.9030103@btc.adaptec.com><20030219212343.O64167@patrocles.silby.com><0d1a01c2d894$c99c0540$52557f42@errno.com><20030220093631.A48177@grasshopper.cs.duke.edu><0dcd01c2d8fc$33a49ee0$52557f42@errno.com> <15957.1002.862520.429817@grasshopper.cs.duke.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
> Sam Leffler writes:
> > > Sam Leffler [sam@errno.com] wrote:
> > > > > On Wed, 19 Feb 2003, Scott Long wrote:
> > > > >
> > > > > > busdma has been around since 3.0. It probably needs a couple
of
> > hours
> > > > > > of work to lock it down.
> > > > >
> > > > > Hm, icky. Is anyone in the know wrt busdma looking into handling
> > that? I
> > > > > don't think we can get much done in the network drivers without
> > touching
> > > > > busdma functions.
> > > > >
> > > >
> > > > Since most bus_dma functions operate on driver-private data locking
> > drivers
> > > > will probably be sufficient to start. The only issue I know of is
that
> > > > bus_dmamem_alloc calls contigmalloc; so there may be an issue there
> > getting
> > > > out from under Giant.
> > > >
> > >
> > > I'm not the most familiar person with the busdma interface.. but..
> > > at least for network drivers, bus_dmamem_alloc() is typically called
> > > for descriptor lists, etc. Eg, data shared with the nic, and is done
> > > at attach time, right? Its never called from the transmit or recv
> > > routines.
> >
> > Correct, for nic drivers you either pre-allocator or you map data
associated
> > with mbufs (or private store if you do jumbograms and set them up as
> > externally-managed storage).
> >
> > In general though, unless you pre-allocate memory you may need to use
it at
> > the point where you setup for dma. The ubsec crypto driver currently
uses
> > it when handling asymmetric crypto ops.
>
> What about bouncing? I assume all bounce buffers are allocated up
> front, so that's not a problem, right?
Bounce buffers are allocated (if needed) when a map is created. But I have
to do this at the same time that I allocate memory because I don't know the
size I need. If I setup a tag and map for the max possible size operand
then I can potentially waste lots of memory because bus_dmamem_alloc will
allocate the max possible size set in the tag and not the size I need.
Since I brought the driver over from openbsd Scott added
bus_dmamem_alloc_size which lets you specify an allocation size different
than the max size specified in the tag. But I haven't switched the driver
to use this.
I think this is getting off topic. I don't believe we can always
pre-allocate memory for doing DMA so we'll always have drivers that need to
malloc buffers on the fly. I don't think this materially affects the
original question which was whether or not the bus_dma support needed
locking work. In looking at the code a bit now it seems there may be issues
synchronizing access to bus_dma_tag_t's that are shared. I suspect this
mostly happens within a driver but there may be some nexus-level tags on
non-x86 architectures that need locking. This might best be handled in the
drivers rather than the bus_dma routines.
Sam
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe cvs-all" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?0e1b01c2d902$b507e270$52557f42>