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

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.

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

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

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


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