Mike Christie wrote:
Mike Christie wrote:
James Bottomley wrote:
On Thu, 2008-02-14 at 11:56 -0600, Mike Christie wrote:
You really don't want to do this. That signals to the block layer
that
we have an iommu, although it's practically the same thing as a 64 bit
DMA mask ... but I'd just leave it to the DMA mask to set this up
correctly. Anything else is asking for a subtle bug to turn up years
from now when something causes the mask and the limit to be
mismatched.
I thought BLK_BOUNCE_ANY just meant "don't bounce anything" (that
was from the blkdev.h comments).
It does ... that's why it's used in the IOMMU case ... and why it's
practically the same as a 64 bit mask.
We used it for iscsi_tcp because the network layer can take any type
of page and will do the right thing for the hardware it eventually
gets sent to.
Right, to you it means never bounce because net wants to do it instead.
However, I don't think that's the case for iSER, is it? ... as in, if
I will leave that to Roland and them :)
Ooops, I misread your mail. I think you are right and for iser we need
to use the ib devices dma values.
For some reason I was thinking you were asking if there was a different
interface which abstracted all that away for us like with iscsi_tcp.
My only concern with a simple patch to use the ib interface's dma
values would be, if there is some event that causes us to start using
inteface ib0 then switch to ib1 (maybe like some sort of route table
change if that is possible), then we will have to loop over all the
scsi devices's queues and update the dma values. And if there is IO
already queued then would we have to possible rebuild those commands
if something like the dma_mask changed?
I guess we can just handle this like how FC handles the case when the
dev loss tmo expires, but then the rport comes back later.
Yuck, I guess we would have to do something like this if ib0 and ib1 had
different dma restrictions.
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
