Mike Christie wrote:
> Erez Zilber wrote:
>> This new thread summarizes and continues a discussion that we (Mike, Or
>> and myself) had outside the list. This is what we have so far:
>>
>>     * Having a parent device: commit
>>       62786b526687db54c6dc22a1786d6df8b03da3f3 in the bnx2i branch looks
>>       ok, and will solve the DMA mask problem. I think that it's cleaner
>>       than calling slave_alloc etc. However, this code cannot be used
>>       outside the bnx2i branch. I think that we need to create another
>>       patch (based on this one) to submit upstream. Mike - what do you
>>       think?
> 
> I am going to push that code soon. Since it is not critical for 2.6.26 I 
> am waiting to push it for .27.
> 
>>     * iSER alignment issue: I'm not sure if we can force our
>>       restrictions through scsi_host_template. Again, the restrictions are:
>>           o The 1st element must end at the page boundary.
>>           o The last element must start at the page boundary.
>>           o All other elements must be page aligned (i.e. start at the
>>             beginning of a page and end at the page boundary).
>>
>>        Can it be done using blk_queue_dma_alignment? pad_mask?
>>
>>     * Host per session or host per IB device: I agree with Or about the
>>       need to have a host per session. I understand that the main
>>       problem that commit 7e8e8af6511afafff33ef7eb0f519bf8702b78ed tries
>>       to solve is what happens if we failover from one IB device to
>>       another, right? We prefer to continue using a host per session,
> 
> It is not related to this.
> 
> It deals with being able to set some limits at a level higher than per 
> session. If we had X sessions on one HCA port then we do not want to 
> always to push X * session->can_queue IOs onto the port because the port 
> may not be able to take that much IO. The commands will time out and the 
> sessions will be stopped, and the scsi eh will run. The problem we face 
> is that the ib_device is per HCA and not per port like we would see with 
> normal scsi pci drivers or iscsi network drivers.
> 
> It deals with aligning data structures to objects that can be removed 
> and handling refcounting in a common way, and aligning this with how we 
> normally do it in the scsi layer. With a normal scsi hba and driver, we 
> have a pci device and allocate a scsi host for it (we actually get a pci 
> resource for each port on the hba and allocate a scsi_host per port). We 
> implement the pci driver's remove and probe callouts which get called at 
> those times.
> 
> Unlike software iscsi for infinniband we have something close to this. 
> We have the ib_client which makes allocating a host per ib_device really 
> nice when having to handle resource limits and handling removal of the 
> host object and the objects accessing it and doing it in a standard way. 
> For example if I remove a broadcom card I will remove the iscsi/scsi 
> host for each port and that will cause each session running on that card 
> to be removed. For iser if I do a host per ib_device and you did 
> something like rmmod the HCA's module then each devices's remove callout 
> gets called. We can then remove the iscsi/scsi host for the ib_device 
> and the iscsi layer will remove the sessions referencing it. And it is 
> all a common code path and there is no special casing for different 
> drivers of this class, and the driver does not need to maintain its own 
> struct to represent what other driver's represent with the scsi_host.
> 

Oh yeah, I am not sure if you saw the end of that thread about this 
item, but I had said I was ok with leaving it as is for now. Because we 
allocate a ib_device per HCA, we run into problems with doing a 
scsi_host per ib_device (when I did the patch I thought we were getting 
a device per port). I am not going to push that patch because of this, 
so we do not have to waste any time on this issue. At this time if you 
are not complaining then I am not either :)

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"open-iscsi" group.
To post to this group, send email to open-iscsi@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/open-iscsi
-~----------~----~----~----~------~----~------~--~---

Reply via email to