From owner-cvs-all Thu Feb 20 8:36: 9 2003 Delivered-To: cvs-all@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3413537B401; Thu, 20 Feb 2003 08:36:05 -0800 (PST) Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id 09D5843FBD; Thu, 20 Feb 2003 08:36:04 -0800 (PST) (envelope-from gallatin@cs.duke.edu) Received: from grasshopper.cs.duke.edu (grasshopper.cs.duke.edu [152.3.145.30]) by duke.cs.duke.edu (8.12.6/8.12.6) with ESMTP id h1KGZx8I008334 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 20 Feb 2003 11:36:00 -0500 (EST) Received: (from gallatin@localhost) by grasshopper.cs.duke.edu (8.11.6/8.9.1) id h1KGZs148341; Thu, 20 Feb 2003 11:35:54 -0500 (EST) (envelope-from gallatin@cs.duke.edu) From: Andrew Gallatin MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15957.1002.862520.429817@grasshopper.cs.duke.edu> Date: Thu, 20 Feb 2003 11:35:54 -0500 (EST) To: "Sam Leffler" Cc: "Mike Silbersack" , "Scott Long" , , , Subject: Re: cvs commit: src/sys/dev/aac aac.c aac_pci.c In-Reply-To: <0dcd01c2d8fc$33a49ee0$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> X-Mailer: VM 6.75 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid Sender: owner-cvs-all@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG 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? Drew To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message