Ted Lemon <mellon@hoffman.vix.com> writes:

>Even modern PCI+ISA and EISA+ISA chipsets support something like this,
>for the same reason.
>
>Frankly, this whole thing sounds to me like nonsense: we have code
>that works.  If we all use the same API, we get to share drivers more
>easily, which is a win for all of us.  If we decide to let our egos do
>the thinking, we all lose.  I have great difficulty imagining how the
>tiny performance differences between the two approaches could matter
>at all to the end user, whereas clearly better device driver support
>will matter a great deal to the end user.

Yes, But it's still not clear to me exactly what Justin sees as the
really significant issues.

To quote Justin again:

} the bus dma framework makes no guarantee that the S/G list is
}allocated in memory that can be dma'ed from, a requirement for many
}clients. 

If the format is different, and you need to translate, then this looks
exactly like what BUS_DMAMEM_NOSYNC was for.  Matt Thomas needed this
for FDDI statistics buffer, and I agitated loundly on behalf of other
NIC-related uses. Did that get added after you forked off the FreeBSD
busdma tree?


}The goal behind these changes was to increase efficiency and flexibility
}without hurting platform independence and I'm certainly interested in
}hearing if I have violated that goal in any way.

I think the "hierarchical" changes do hurt platform independence,
prety badly, and I've said why.  I'm interested in hearing Justin's
answer.

But if the real problem is memory exhaustion in some configurations
(e.g., ISA machines with 3 ISA SCSI cards want an unreasonable amount
of the <= 16M memory) then that seems like a genuine problem.  I dont
see that it's ncessary to change the API in an incompatible way to fix
that, though.

The other feature is adding a layer to let driver-level code construct
a device-dependent representation of a dmamap.  If I'm grokking this,
that just doesn't work on _some_ implementations of standard buses:
you *have* to perform host-bridge-specific actions, and those *need* a
non-device-dependent representation of the dmamap. 

I think that's a basic correctness issue, not just a "portability"
issue.  I'm told high-end DEC ALpha PCI buses work this way.  If
FreeBSD is porting to ALphas, isn't that a concern for FreeBSD
also?Again, I may be misunderstanding, and I'd be interested in
Justin's reply.

That aside, has anyone got hard, measured numbers on how much the
device-specific "SG" changes buy in performance (as opposed to space)?

I think the device-specific filter sounds like a good idea, if it's
really the best place to catch weird DMA bugs.  Maybe that is worth
buying back. I guess it's up to Jason, though.

Justin again:

}The client must assume that the lifetime of the passed in bus_dma_segment
}array is that of the callback function.  Having static space allocated to
}hold the mapping is of no use to the client in typical practice.

There are buses (DEC TC machines with ioctl asics, and some Sparcs)
where the DMA engines only have one hardware mapping register (or one,
double-buffered), and the DMA engine interrupts to request a software
reload on each physical page crossing.  On those buses, a static map
*is* useful in the typical case. At least, I think it is.