> This is pretty cool stuff, but I have some suggestions on how to make
> it better :-)
Cool.

> You really don't want to use a VM map to make the clusters.  This can have
> painful side-effects on some architectures, esp. since you are using
> kmappings ... this is basically not going to work on any platform which has
> a virtually-indexed cache.
OK.  That's b/c these machines cant't handle VA aliases in the cache,
so aliases aren't allowed on them?  Is there some way to inval the cache,
in that case?  And are there other reasons why it won't work?
I ask to both understand and to try to support clusters on those configs
that don't bus_dma.

> Instead, I suggest using uios to describe the clusters.  Make a flag
> called B_UIO for the buf structure, and when that is set, b_data points
> to a uio structure.  When you build a cluster, allocate a uio and an iovec
> array (maybe always allocate an iovec array large enough to handle up to
> some max_cluster requests).
> 
> ....then modify the SCSI HBA drivers to use bus_dmamap_load_uio instead
> of bus_dmamap_load when they see B_UIO.  Note that there is already some
> #if 0'd code for this in some HBA drivers (historical reasons).
A buddy of mine had pointed out that code and suggested this
approach, too.  Makes sense to me, so that's what I'll aim for.

> It would also be nice if the building of clusters were hidden inside the
> BUFQ interface.  I suggest adding a new flag when the bufq is allocated,
> BUFQ_CLUSTER, or something.
I think I like this, too.

> Now, for devices which aren't using bus_dma, we could just avoid setting
> BUFQ_CLUSTER in those cases.  They won't get the benefit of clustering, but
> they will also continue to work.
Hm.  I could have 2 clustering methods, one that uses bus_dma, one that
uses VM tricks.  Prefer bus_dma over VM, prefer VM over nothing, and
force nothing if the VM h/w for the system can't dtrt?  If BUFQ_CLUSTER
is set on machines that can't support them, it'd just be ignored.

>         -- Jason R. Thorpe <thorpej@wasabisystems.com>
Chris <jepeway@blasted-heath.com>.