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érard.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
