Or Gerlitz wrote:
>>>> One of the reasons for the scsi_host to resource mapping is to support
>>>> hotplug/unplug. For example if you remove a HBA the pci remove
>>>> functions are called and you would tear down the structures. For
>>>> iscsi_tcp we do not know about the hardware so we do not support this.
>>>> For iser one of things you have been having trouble supporting is if I
>>>> did rmmod my_hca_module. If we implemented iser similar to srp where
>>>> we have a ib_client, then on the ib_client remove call we can just
>>>> clean up the scsi_host (that is not implemented in the bnx2i trees).
>>> Unlike SRP, iSER runs over cma (CM abstraction). If the HCA driver is
>>> removed, we get a notification from the cma (which is an ib client, and
>>> gets a notification about device removal). Is there a problem with the
>>> current code?
>>
>> It is ugly in that it leaves the sessions hanging and iscsid continues
>> to try and reconnect and the log fills up with errors. You could
>> actually fire the new event I added for this and it would get cleaned up.
>>
> Mike,
> 
> With the latest code, iser have hot unplug event being treated as disconnect
> and hence as you
> say the user space daemon keeps attempting to reconnect where there's no
> device down there.
> This can easily be fixed in the fashion you describe here with new event
> delivered from iser to the user
> space daemon. I am more concerned from  the design of the other direction,
> do you want some trap to be sent
> from iser to the daemon telling it "you can connect now"? this would be more
> involved (and nice...) to design.

For bnx2i I was going to run from a hotplug event. When the bnx2i card 
is loaded or a port is setup I was going to have it look for session 
that are bound to it and login.

For iser if we did a host per ib_device we could do the same thing. If 
you do not do a host per device then you should add something in hca 
modules events? You would want to handle the actually removing of 
modules and if the card is hotunplugged.


> 
> What do we do if you leave the module loaded, but hotunplugged the card btw?
> 

If you had two cards and one went bad, you do not want to stop the 
system and you do not even want to sop traffic on the other card since 
it might be used for backup/HA. If this was a normal scsi hba, we would 
remove the bad hba from the machine and swap in a new one. This is where 
the pci probe and remove functions come into place for hotplug.

> Good question, do you think we should handle this case?

If you guys want to support HA then you should.

> 
>> how iser allocates a scsi_host boarders wrong like I said many times in
>> this
>> thread now. I say boarders because we want to do a host per port, and
>> ib_device is per hca, so we are sort of hacking around this and hacking
>> around coding limitations is normally wrong.
>>
> Sorry but I don't agree that "we want to do a host per port" currently its
> host per connection and
> connection is over specific port. There's an obvious fix to apply, the one
> that also sets the parent of the
> scsi host to be the dma device of the ib device used for this connection,
> but expect for that I was thinking
> that we are still in the process of debating on the what is the correct
> primitive to associate scsi host with, no?
> 

I do not think it matters right now, unless you have nothing to do and 
want to debate this for the fun of filling up peoples mailboxes. I think 
if we can use the SCSI APIs like other drivers then there is solution 
which we should follow. The subsystem iser uses does not provide what we 
need right now, so I said before that we can leave it as a host per 
sessions since going to a host per HCA is not right either and will 
cause new problems. So I said I am not going to push my patch for this 
right now.  I am only going to push my patch for the host parent fix.

--~--~---------~--~----~------------~-------~--~----~
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