From owner-freebsd-hackers Mon Jan 14 13:46:42 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mail.libertysurf.net (mail.libertysurf.net [213.36.80.91]) by hub.freebsd.org (Postfix) with ESMTP id 5F33D37B425 for ; Mon, 14 Jan 2002 13:46:26 -0800 (PST) Received: from [192.168.1.129] (212.129.9.190) by mail.libertysurf.net (5.1.053) id 3C40421000062AAC; Mon, 14 Jan 2002 22:45:46 +0100 Date: Mon, 14 Jan 2002 22:45:23 +0100 (CET) From: =?ISO-8859-1?Q?G=E9rard_Roudier?= X-X-Sender: To: "Justin T. Gibbs" Cc: Phungte Ha , Subject: Re: bus_dmamap_load change request. In-Reply-To: <200201142059.g0EKxdg30516@aslan.scsiguy.com> Message-ID: <20020114222148.X2771-100000@gerard> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Mon, 14 Jan 2002, Justin T. Gibbs wrote: > >Hi all, > > > >Currently bus_dmamap_load builds the dma descriptor in a table on the > >stack. > >This cause us following problems: > > . our dma can be large, 1MB or more, this forces us to increase the > >kernel stack size. > > . our hardware would be happy with the dma descriptors as they are, > > address and length. Unfortunately, with the table on the stack, > > as soon the callback returns, we cannot count on this table anymore. > > Most drivers cannot use the passed in format as is. The fact that > the format may change if the platform changes (consider that even the > addition of PAE support on x86 might change the format), makes the > "conversion" into a local, per-transaction list a requirement for a > well designed driver. > > >Can we either change the IF, or having another IF which accepts as > >arguments the table address and a number of entries. The caller will > >be in charge of allocate and free this table. > > I changed the code locally a while back to allocate the table during > the allocation of the dma tag. This seems to work, but I just haven't > gotten back to it to think through all of the consequences. Whatever > the solution, we don't want to device a solution where most drivers > have allocated 2X their required S/G list size. Most other O/Ses seem to pay for the dmamap abstraction this 100% allocation overcost. This is indeed a pity for >95% of systems currently using FreeBSD (IA32) that donnot actually require such overallocation. What about supplying several dmamap (create/load/...) methods, for example: 1) A one shot load method for reasonnable known map size that does not overallocate if not required by arch. (the one we have) 2) A one shot method that may overallocate depending on arch and/or map size (may use method #1 when possible). 3) A multi-shot method that may not overallocate if not needed for arch. By multishot, I mean the callback may be called several times with partial map + some more flag. Hmmm... This indeed inject additionnal complexity into already complexified places ... :) G=E9rard. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message