Messages in this thread | | | Subject | Re: [RFC] block layer support for DMA IOMMU bypass mode | From | James Bottomley <> | Date | 02 Jul 2003 10:52:38 -0500 |
| |
On Tue, 2003-07-01 at 18:01, Grant Grundler wrote: > > The bio layer works with > > a nice finite list of generic or per-queue constraints; it doesn't care > > currently what the underlying device or IOMMU does. > > I don't agree. This whole discussion revolves around getting BIO code and > IOMMU code to agree on how block merging works for a given platform. > Using a callback into IOMMU code means the BIO truly doesn't have to know. > The platform specific IOMMU could just tell BIO code what it wants to > know (how many SG entries would fit into a limited number of physical > mappings).
Ah, but the point is that currently the only inputs the IOMMU has to the bio layer are parameters. I'd like to keep it this way unless there's a really, really good reason not to. At the moment it seems that the proposed parameter covers all of IA64's needs and may cover AMD64's as well.
> > Putting such a callback in would add this entanglement. > > yes, sort of. But I think this entanglement is present even for machines > that don't have an IOMMU because of bounce buffers. But if ia64's swiotlb > would be made generic to cover buffer bouncing....
Well, not to get into the "where should ZONE_NORMAL end" argument again, but I was hoping that GFP_DMA32 would elminate the IA64 platform's need for this. __blk_queue_bounce() strikes me as being much more heavily exercised than the swiotlb, so I think it should be the one to remain. It also has more context information to fail gracefully.
James
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |