On 04/09/2014 07:37 AM, Or Gerlitz wrote: > On 06/03/2014 20:01, Mike Christie wrote: >> On 02/27/2014 04:20 PM, Or Gerlitz wrote: >>> Hi Mike, >>> >>> We're working now on sort of house cleaning w.r.t the iser transport >>> code that deals with connections tear-down and resources cleanups. >>> Examining the iscsi state machine ladder diagram for connection >>> establishment and login which goes like: >>> >>> 01 transport end-point (create and) connect >>> 02 create session >>> 03 create connection >>> 04 bind iscsi connection to the transport connection >>> 05 set non-negotiated params >>> 06 send/recv login request/response >>> 07 set negotiated params >>> 08 start connection >>> >>> [etc] >>> >>> A possible oredering for normal termination could have been something >>> like: >>> >>> 09 stop connection >>> 10 send/recv logout request/response >>> 11 unbind iscsi connection from the transport connection >>> 12 destroy connection >>> 13 destroy session >>> 14 transport end-point disconnect (and destroy) >>> >>> In reality it's not the case -- there's no unbind primitive and the >>> actual order is the following: >>> >>> 09 send/recv logout request/response >>> 10 transport end-point disconnect (and destroy) >>> 11 stop connection >>> 12 destroy connection >>> 13 destroy session >>> >>> Just to make sure, I got it right, correct? >>> >> Yeah, no unbind callout for ep. >> >>> Now, under this design, we consider the transport end-point disconnect >>> to be interpreted as >>> >>> 10.1 unbind iscsi connection from the transport connection >>> 10.2 disconnect >> Yes. Depending on how the driver's binding from the iscsi connection to >> the endpoint connection it can be disconnect then unbind or unbind >> then disconnect. > > Mike, > > So we're back on that with Ariel from our team working on the changes. > In this context I assume unbinding in your reply is part of the conn > stop flow. With this in mind, if someone initiates a disconnection while > there are inflight SCSI commands or other PDUs (nops, etc), with the > current flow being > > 09 send/recv logout request/response > 10 transport end-point disconnect (and destroy) > 11 stop connection > > The transport must be able to issue their cleanup_task callback > **before** conn_stop > has been called, since that latter will eventually issue > fail_iscsi_tasks --> fail_scsi_task --> iscsi_complete_task --> > __iscsi_put_task --> iscsi_free_task --> session->tt->cleanup_task(task)
Do you need to put something on the wire when you are cleaning up, or is it because the per task resources are tried to the ep related structs so it is easier to manage, or something else? > > Now, discussing a possible change in iser which will simplify thing, we > took a look on the be_iscsi driver and noted that beiscsi_ep_disconnect > actually destroys all the objects, specifically the beiscsi connection, > so in that respect, > we can't understand what happens when beiscsi_cleanup_task is called > from iscsi_conn_stop?! do we miss something here? > I am not sure what you are asking or what you are seeing. Are you saying that be2iscsi's ep_disconnect cleans up the task related structs? -- You received this message because you are subscribed to the Google Groups "open-iscsi" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/open-iscsi. For more options, visit https://groups.google.com/d/optout.
