Date: Mon, 14 Jan 2002 15:01:17 -0700 From: "Justin T. Gibbs" <gibbs@scsiguy.com> To: =?ISO-8859-1?Q?G=E9rard_Roudier?= <groudier@free.fr> Cc: Phungte Ha <phungte@decru.com>, hackers@FreeBSD.ORG Subject: Re: bus_dmamap_load change request. Message-ID: <200201142201.g0EM1Hg31707@aslan.scsiguy.com> In-Reply-To: Your message of "Mon, 14 Jan 2002 22:45:23 %2B0100." <20020114222148.X2771-100000@gerard>
next in thread | previous in thread | raw e-mail | index | archive | help
>> 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. There is only 1 tag to several maps. If you allocate one extra S/G list per-tag, then your "overallocation" is 1/nmaps. The current scheme using the stack gives 0 over allocation, but isn't too nice for other reasons. I also don't completely understand your claim that overallocation is not required for IA32. Is this because you feel the driver should do the mapping loop and store the results into its own, taylored to its dma engine, structure? It is hard to find a mapping abstraction that avoids a conversion. >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. The question for all of these methods is, "where is the mapping list stored?" That would help me understand your proposal. -- Justin 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?200201142201.g0EM1Hg31707>