Mike Christie wrote: >> the noop-out based watch-dog serve all transports, correct? > Yes
okay >> narrow down things and understand if/what is the transport role: > For the nop out path, the trasnport just has to send/recv the nop pdu/response okay, fair-enough > They do not have to make those calls for multipath to work. Multipath > will work better if the transport can signal when there is a problem, > because we can stop using a bad path and get IO going to a working path > faster. If the transport does nothing then we have to rely on the scsi > error handler/timeout to detect the problem and that is very slow. I am still confused, in somehow black box manner, I understand and see (...) that: A) the nop out based watch-dog serves all transports B) if/when the transport doesn't signal to iscsi there's a problem with a session multipathing works much more slower. combining A && B I still don't see what is the exact role of the watch-dog, anyway, maybe you should let me get some more millage on the thing and I'll get that... > You should also change your ep_disconnect because it is not > supposed to block (did we talk about this or was this just bnx2i), since > it will stop iscsid from processing other events. no, I didn't realized ep_connect shouldn't block up till we brought it here. Couples of years back when we did ep_connect/poll/disconnect we said that ep_connect initiates the connection establishment process and ep_poll reports about the progress. It turns out that I didn't pay attention to the price payed when ep_disconnect blocks. Let me take a look if I can just change it internally in iser or a patch to iscsi is needed, thanks for pointing this out! Or. -- You received this message because you are subscribed to the Google Groups "open-iscsi" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/open-iscsi?hl=en.
