From owner-freebsd-arch@FreeBSD.ORG Sat Jun 28 19:03:06 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BDFC237B401; Sat, 28 Jun 2003 19:03:06 -0700 (PDT) Received: from magic.adaptec.com (magic-mail.adaptec.com [208.236.45.100]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2D77744005; Sat, 28 Jun 2003 19:03:06 -0700 (PDT) (envelope-from scottl@freebsd.org) Received: from redfish.adaptec.com (redfish.adaptec.com [162.62.50.11]) by magic.adaptec.com (8.11.6/8.11.6) with ESMTP id h5T228811793; Sat, 28 Jun 2003 19:02:08 -0700 Received: from freebsd.org (hollin.btc.adaptec.com [10.100.253.56]) by redfish.adaptec.com (8.8.8p2+Sun/8.8.8) with ESMTP id TAA27563; Sat, 28 Jun 2003 19:03:02 -0700 (PDT) Message-ID: <3EFE48E8.1040700@freebsd.org> Date: Sat, 28 Jun 2003 20:03:20 -0600 From: Scott Long User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.3.1) Gecko/20030425 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Justin T. Gibbs" References: <3EFDC2EF.1060807@freebsd.org> <2768600000.1056836005@aslan.scsiguy.com> In-Reply-To: <2768600000.1056836005@aslan.scsiguy.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-arch@freebsd.org Subject: Re: API change for bus_dma X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Jun 2003 02:03:07 -0000 Justin T. Gibbs wrote: >>Ok, after many semi-private discussions, how about this: > > > There is only one problem with this strategy. The original idea > of using a mutex allowed the busdma API to use that same mutex as > the strategy for locking the fields of the tag, dmamap, etc. In > other-words, the agreement would have been that the caller always > has the lock held before calling into bus dma, so that bus dma > only has to grab additional locks to protect data shared with > other clients. For this to work in the more general scheme, you > would have to register "acquire lock"/"release lock" functions in > the tag since locking within the callback does not allow for the > protection of the tag or dmamap fields in the deferred case (they > would only be protected *during* the callback). > > Again, what we want to achieve is as few lock acquires and releases > in the common case as possible. For architectures like x86, the only > data structure that needs to be locked for the common case of no deferral > and no bounce page allocations is the tag (it will soon hold the S/G list > passed to the callback). Other implementations may need to acquire other > locks, but using the client's lock still removes one lock acquire and > release in each invocation that is not deferred. > > -- > Justin > > This is becoming wonderfully complex. What is the purpose of storing the S/G list in the tag? Are we going to enforce a 1:1 relationship between tags and maps? That would really suck for the aac(4) driver. Scott