>>>     * 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 :)
Yeah, I saw that you said that we have several options. Let's not change
it for now.


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