Re: [PATCH 1/3] iscsi iser: remove DMA restrictions

[Mike Christie <michaelc@cs.wisc.edu>]

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.