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)
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?
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/d/optout.
