RE: ISCSI: Unsolicited data in draft v12

["Julian Satran" <Julian_Satran@il.ibm.com>]

I am with John here (the third guy that is right) - why would an implementer have separate buffers for solicited and unsolicited data?

Julo

"BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2)" <matthew_burbridge@hp.com> 08-04-02 21:43 Please respond to "BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2)"

To:        John Hufferd/San Jose/IBM@IBMUS, "BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2)" <matthew_burbridge@hp.com>         cc:        Julian Satran/Haifa/IBM@IBMIL, Rod Harrison <rod.harrison@windriver.com>, ips@ece.cmu.edu, owner-ips@ece.cmu.edu         Subject:        RE: ISCSI: Unsolicited data in draft v12

John,

It's not so much an implementation problem but one resource management
problem in that if unsolicited data has been negotiated then target MUST
pre-allocate buffers with which to store the unsolicited when it arrives.
The target implementors will decided whether they want to use unsolicted
data and take the buffer resource hit in doing so.  However, if they do wish
to take this hit but the initators decide not to use unsolicited data (even
though they have negotiated to use it) then there is potientially a lot of
valuable buffer resources tied in up for unsolicited data but which is not
being used.

Matthew

-----Original Message-----
From: John Hufferd [mailto:hufferd@us.ibm.com]
Sent: Monday, April 08, 2002 11:13 AM
To: BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2)
Cc: 'Julian Satran'; Rod Harrison; ips@ece.cmu.edu;
owner-ips@ece.cmu.edu
Subject: RE: ISCSI: Unsolicited data in draft v12



Please explain, why an initiator deciding to not send unsolicited data for
a specific command causes an implementation problem.  That was not clear
from your statements.  You still need the R2T capability, so what is lost?

.
.
.
John L. Hufferd
Senior Technical Staff Member (STSM)
IBM/SSG San Jose Ca
Main Office (408) 256-0403, Tie: 276-0403,  eFax: (408) 904-4688
Home Office (408) 997-6136, Cell: (408) 499-9702
Internet address: hufferd@us.ibm.com


"BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2)" <matthew_burbridge@hp.com>
@ece.cmu.edu on 04/08/2002 10:25:55 AM

Sent by:    owner-ips@ece.cmu.edu


To:    "'Julian Satran'" <Julian_Satran@il.ibm.com>, Rod Harrison
       <rod.harrison@windriver.com>
cc:    ips@ece.cmu.edu, owner-ips@ece.cmu.edu
Subject:    RE: ISCSI: Unsolicited data in draft v12



I must express my concern on this issue.  From a target point of view once
it has negoiated the use of unsolicited data it has to allocate buffer
space
for that unsolicited data.  Now depending on the various parameters this
may
be a sizeable chunk of valuable resources which it is making available.
Now
if the decision to use unsolicited data is being moved from a per session
to
per task basis (which is what this change effectively does) then it puts an
awful lot of resource overhead on the target which may never be used.

For the reasons above I propose that we do not relax the v12 restriction
and
keep it as:

"An iSCSI initiator MUST send as unsolicited data either the negotiated
amount or all the data if the total amount is less than the negotiated
amount for unsolicited data."

Matthew Burbridge
Principal Engineer
NSAS-Bristol
Hewlett Packard

-----Original Message-----
From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
Sent: Monday, April 08, 2002 9:36 AM
To: Rod Harrison
Cc: ips@ece.cmu.edu; owner-ips@ece.cmu.edu
Subject: Re: ISCSI: Unsolicited data in draft v12



OK - Julo


"Rod Harrison" <rod.harrison@windriver.com>
Sent by: owner-ips@ece.cmu.edu
08-04-02 14:52
Please respond to "Rod Harrison"

        To:        <ips@ece.cmu.edu>
        cc:
        Subject:        ISCSI: Unsolicited data in draft v12





                I propose we slightly relax the new restriction in draft
v12
that the
initiator MUST send the maximum permissible amount of unsolicited data. I
suggest we change the rule to allow the initiator to either send no
unsolicited data, or the maximum permissible.

                There is no difficulty for the target here since the lack
of
unsolicited
data will be clearly indicated by a command PDU with F bit set and
dataSegLen=0. The target will have all the information it needs to
immediately issue R2Ts as appropriate.

                I believe the initiator should be able to make a policy
decision on which
individual commands should be sent with unsolicited data and which should
not.

                In draft 11.91 section 2.2.4 I suggest we change

"An iSCSI initiator MUST send as unsolicited data either the negotiated
amount or all the data if the total amount is less than the negotiated
amount for unsolicited data."

                to something like

"An iSCSI initiator MAY choose to send no unsolicited data with a command,
or if any unsolicited data is sent it MUST be either the negotiated amount
or all the data if the total amount is less than the negotiated amount for
unsolicited data."

                - Rod