[iser-dev] iSER use case: iSER login

[Peter Dunlap]

Hi Rick,

Jesse's use case document is attached -- I think he sent it out before 
you were subscribed.

Rick McNeal wrote:
> Isn't there a requirement to use the same transport that the login was
> received on? Am I missing something here?
>   

iSER connections are always initiated using sockets.  From a physical 
standpoint yes the transport remains the same but we change from using 
the IDM socket transport code to some other transport module (iSER).

-Peter

> I can't comment on any of your other questions since Jesse's document
> wasn't attached to your open-solaris reply.
>
> On Jan 11, 2008 2:07 PM, Peter Dunlap <Peter.Dunlap at sun.com> wrote:
>   
>> I think I'm missing some of the underlying assumptions for this use
>> case, so let me start by asking some clarifying questions:
>>
>> 1. Suppose more than one DataMover transport is available, how do we
>> pick the correct transport?
>>
>>     - Do we have an implicit assumption that only one DM transport in
>> our list will be usable?  We can anticipate iSER-iWarp in addition to
>> iSER-IB but only one or the
>>     other will be viable for any given connection.
>>
>> 2. The use case shows IDM functions but I'm kind of assuming these are
>> actually transport ops... idm_alloc_conn_rsrcs is actually
>> transport_ops_t.transport_alloc_conn_rsrc.  True?  If so my suggestion
>> would be to replace "idm_" with "transport_" to avoid confusion.
>> Otherwise if these are actually IDM functions exposed to the client then
>> we will need to add them to the design doc.
>>
>> 2a.  Do these functions get called from the IDM client?  A function like
>> idm_notice_key_values would certainly need to be called from the
>> client.  Some of the others like idm_enable_datamover and
>> idm_alloc_conn_rsrcs should be callable from within the IDM connection
>> state machine.  Or at least it seems so to me.
>>
>> 3.  What does this picture look like if no DM protocols are available --
>> not really looking for a complete use case but do we still call
>> idm_notice_key values and the other functions?
>>
>> 4.  How does idm_notice_key_values work?  Given the modular transport
>> API that you've defined, I don't think we want to make the clients
>> negotiate transport-specific keywords.  iscsit maintains three nvlists
>> of parameters during login:
>>
>> 1. request keywords -- nvpairs from the latest login request
>> 2. response keywords -- nvpairs intended for the login response
>> 3. negotiated keywords -- nvpairs representing parameters that have been
>> successfully negotiatiated.
>>
>> I think for idm_notice_key_values to be modular the clients would need
>> to pass these three nvlists -- the transport can then modify the
>> response list if it needs to "counter" the login request or select a
>> value and it can add any transport specific negotiated values to the
>> negotiated keywords list.
>>
>> Looking some more at the transport API I'm thinking it might make sense
>> to add a transport private field in the idm_conn_t structure.  Certainly
>> some of the current idm_conn_t fields are specific to sockets and there
>> will be iSER specific fields as well.  An interesting point to ponder:
>> At the time of the call to idm_alloc_conn_rsrcs (if not before) don't we
>> need both a socket transport context and an iSER transport context?
>>
>> -Peter
>>
>> Jesse Butler wrote:
>>     
>>> Hello-
>>>
>>> Please find attached my first use case slide for iSER. It represents
>>> the flow between the iSCSI, IDM and transport layers on the intiator
>>> and target required for transition to iSER-assisted mode during iSCSI
>>> login.
>>>
>>> This sheet is based upon Priya's IDM use cases, thanks Priya.
>>>
>>> More use cases will follows as I put them together. They will help a
>>> great deal I think with implementation. Please let me know what your
>>> thoughts are (any holes, ambiguities, etc).
>>>
>>> Best,
>>> Jesse
>>>
>>> ------------------------------------------------------------------------
>>>
>>> _______________________________________________
>>> iser-dev mailing list
>>> iser-dev at opensolaris.org
>>> http://mail.opensolaris.org/mailman/listinfo/iser-dev
>>>       
>> _______________________________________________
>> iser-dev mailing list
>> iser-dev at opensolaris.org
>> http://mail.opensolaris.org/mailman/listinfo/iser-dev
>>
>>     
>
>
>
>   

-------------- next part --------------
A non-text attachment was scrubbed...
Name: iser_usecases.ods
Type: application/vnd.oasis.opendocument.spreadsheet
Size: 52151 bytes
Desc: not available
Url : http://mail.opensolaris.org/pipermail/iser-dev/attachments/20080111/2b436ee6/attachment-0001.ods