On Fri, Feb 28, 2014 at 12:20 AM, Or Gerlitz <[email protected]> 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: > To be clear, the subject of the email was a bit misleading (and not b/c of the typo with "thoughts")... it's about the iscsi stack state-machine as managed by iscsid, we want to make sure we understand it right before doing the fixes @ iser > > 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? > > 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 > > and this design is OK with us. We just want to make sure that after > issuing the disconnect call, the iscsi layer will not attempt to do > anything with the iscsi connection expcet for stopping/destroying it > or binding it to **new** transport end-point which was > created/connected through the recovery flow. > > In this case, the iser entries planted for the below callbacks would > just be direct pointers into libiscsi service routines > > stop connection - iscsi_conn_stop() > destroy connection - iscsi_conn_teardown() > destroy session - new function iscsi_session_destroy (*) > > (*) today we use iscsi_session_teardown, and we need to add there > calls to iscsi_host_remove () and iscsi_host_free() > > So how all this sounds? I tend to think that in the past stop_conn > used to be before sending the logout request, is that true? > > Or. > -- 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/groups/opt_out.
