>On Thu, 11 Jun 1998 16:32:47 -0600 
> "Justin T. Gibbs" <gibbs@plutotech.com> wrote:
>
> > In NetBSD, the dma map contains the S/G list of the mapping as well as
> > any implementation private data required to perform the mapping.  In
>
>It's not an S/G list.  It is a list of DMA segments.  There is a subtle,
>but real, difference.

Fair enough.

>It also contains other non-private data used during map sync operations.

The only non-private members I see in the x86 implementation are these:

        /*
         * PUBLIC MEMBERS: these are used by machine-independent code.
         */
        bus_size_t      dm_mapsize;     /* size of the mapping */
        int             dm_nsegs;       /* # valid segments in mapping */
        bus_dma_segment_t dm_segs[1];   /* segments; variable length */

Are dm_mapsize and dm_nsegs really crucial for synchronization events on
the x86?  I'm not arguing that it may be necessary to have this data in
the dma maps for other bus/arches, I'm only asking if the data is strictly
necessary for all bus/arches.  If so, why?

>Maybe you're not up to speed on what the NetBSD bus_dma interface actually
>looks like.

I just synch'ed my tree and the files didn't seem to change.  Hmm.

> > Maybe you should go look at the code?  Or perhaps someone who has can
> > better describe how the interface is different.
>
>I looked at the code.  Before I comment on it, I want to see your
>design document (like the ones I posted to tech-kern during the design
>phase of bus_dma).

You'll have to wait until after USENIX then.

> > I was talking about static storage of the MI S/G list. My complaint is that
> > a large portion of what is in the dma map (the MI S/G list) doesn't need to
> > be in the map at all and that by including it there, the implementation is
> > forced to consume more memory space than it might otherwise have to.
>
>Yes, but as has been previously stated, including it in the map can avoid
>inefficiency on other platforms.

And what in my API prevents you from including this data in the dma map
object when it makes sense to do so?

>If you're really that concerned about it, then by all means quantify it
>for us.
>
>Actually, let me do this.  Let's use the BusLogic driver as an example.
>
>The i386 DMA map has 8 4-byte quantities + 17 8 byte quantities in each
>map used by the bha driver.  That's 168 bytes.  It currently allocates
>32 DMA maps for transfers, plus one for the mailboxes, for a total
>of 33.  That's a total of 5544 bytes.  That's not really very much.
>
>That, BTW, assumes that we have allocated the maxiumum number of maps.
>If there aren't enough targets on the bus to warrant that many maps,
>the usage is less.

Thanks for reminding me about the deficiencies of the NetBSD BusLogic 
driver.  If the driver was decent and supported tagged queuing, instead
of 32 maximum concurrent transactions, you would support 192 as the FreeBSD
CAM driver does.  You also assume that the maximum transfer size will 
remain at 64k, something I'm surprised you would assert considering the
mass storage project being built where you work.  Even if we assume 64k
max mapping size, were still looking at 32k of memory wastage that
FreeBSD's implementation doesn't have.  I'll admit the case for bounce
buffers is more compelling, but as soon as you talk about decent sized
transfers, the memory wastage for dm_seg data becomes compelling as well.

>Jason R. Thorpe                                       thorpej@nas.nasa.gov
>NASA Ames Research Center                            Home: +1 408 866 1912
>NAS: M/S 258-5                                       Work: +1 650 604 0935
>Moffett Field, CA 94035                             Pager: +1 650 428 6939
>

--
Justin