Date: Mon, 14 Jan 2002 22:45:23 +0100 (CET) From: =?ISO-8859-1?Q?G=E9rard_Roudier?= <groudier@free.fr> To: "Justin T. Gibbs" <gibbs@scsiguy.com> Cc: Phungte Ha <phungte@decru.com>, <hackers@FreeBSD.ORG> Subject: Re: bus_dmamap_load change request. Message-ID: <20020114222148.X2771-100000@gerard> In-Reply-To: <200201142059.g0EKxdg30516@aslan.scsiguy.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020114222148.X2771-100000>