|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: iSCSI: changing MaxPDUDataLength
Mallikarjun,
The question was general and not specific to MaxRecv....
Although we say that negotiation is symmetric we don't have any mechanism
through which a target can say it wants to start negotiation something
(sort of similar but not as strong as a the "request logout" - "request to
negotiate" that will require the initiator to issue a text request and
kick-off a negotiation.
Julo
"Mallikarjun C."
<cbm@rose.hp.com> To: <ips@ece.cmu.edu>, Julian Satran/Haifa/IBM@IBMIL
Sent by: cc:
owner-ips@ece.cmu Subject: Re: iSCSI: changing MaxPDUDataLength
.edu
06/11/2002 10:50
PM
Please respond to
"Mallikarjun C."
> I also realized that we don't have "negotiation prompt" from the target.
> I am not sure that we need one.
I am not sure about it either.
My preference is not to add this. It appears to me that a target does have
the option of dropping the connection today if it can't work with
non-ULPDU-contained
segments for too long. I suspect that the target would do the same if (we
introduced the "negotiation prompt" and) the initiator doesn't/couldn't
honor the
"negotiation prompt".
Thanks.
--
Mallikarjun
Mallikarjun Chadalapaka
Networked Storage Architecture
Network Storage Solutions
Hewlett-Packard MS 5668
Roseville CA 95747
cbm@rose.hp.com
----- Original Message -----
From: "Julian Satran" <Julian_Satran@il.ibm.com>
To: <ips@ece.cmu.edu>
Sent: Tuesday, June 11, 2002 8:34 AM
Subject: RE: iSCSI: changing MaxPDUDataLength
> I suggest the following text in 11.13
>
> A change of MaxRecvDataSegmentLength by an initiator or target
> becomes effective after all commands preceding the negotiation
> end-ing request have been processed by the target and their status
> is acknowledged.
>
> I also realized that we don't have "negotiation prompt" from the target.
> I am not sure that we need one.
> If some of you think we need we may want one additional code in the
Asynch
> Message.
> Please comment TODAY.
>
> Julo
> ----- Forwarded by Julian Satran/Haifa/IBM on 06/11/2002 06:29 PM -----
>
> Julian Satran
> To: Eddy Quicksall
<eddy_quicksall@ivivity.com>
> 06/11/2002 04:04 cc: ips@ece.cmu.edu,
pat_thaler@agilent.com
> PM From: Julian
Satran/Haifa/IBM@IBMIL
> Subject: RE: iSCSI:
changing MaxPDUDataLength(Document link:
Julian Satran - Mail)
>
>
>
>
>
>
>
>
>
> That is a fair request - we may slip in a recommendation to that effect
(in
> chapter 11?)
>
> Julo
>
>
>
> Eddy Quicksall
> <eddy_quicksall@i To: Julian
Satran/Haifa/IBM@IBMIL
> vivity.com> cc: ips@ece.cmu.edu,
pat_thaler@agilent.com
> Subject: RE: iSCSI:
changing MaxPDUDataLength
> 06/11/2002 04:28
> AM
> Please respond to
> Eddy Quicksall
>
>
>
>
>
> How about if we say that an initiator must not change the MaxPDUDataSize
> unless it first idles the commands (at least the ones with the R bit) or
if
> ErrorRecoveryLevel==0?
>
> That would simplify target code greatly and would meet the design goals;
> and since it should be rare to change it, it would be of little impact to
> idle the commands for a split second.
>
>
> Eddy
> -----Original Message-----
> From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
> Sent: Monday, June 10, 2002 8:06 PM
> To: Eddy Quicksall
> Cc: ips@ece.cmu.edu; pat_thaler@agilent.com
> Subject: RE: iSCSI: changing MaxPDUDataLength
>
>
> I said only that when you change length you can ask for all PDUs
> after the ack! (no need to keep a tall - the old offsets are good
up
> to the hole).
>
> Julo
>
>
> Eddy Quicksall
> <eddy_quicksall@ivivity.com> To: Julian
> Satran/Haifa/IBM@IBMIL
> cc: ips@ece.cmu.edu,
> 06/11/2002 12:32 AM pat_thaler@agilent.com
> Please respond to Eddy Quicksall Subject: RE: iSCSI:
> changing MaxPDUDataLength
>
>
>
>
>
>
>
> Julian,
>
> Another problem here is that the target has to calculate the offset
> from the DataSN #. And as BegRun can be any value. E.g., BegRun=4
and
> RunLngth=0 means starting DataSN=4, send all the data for that
> sequence.
>
> I think it would be a performance hit and waist of memory to keep a
> tally of all PDU sizes just for an occasional SNACK.
>
> It's not that it can't be done ... it is more that it is messy and
I
> think there is a solution that will satisfy the design requirements
> but keep the software simpler.
>
> Eddy
> -----Original Message-----
> From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
> Sent: Saturday, June 08, 2002 10:16 PM
> To: Eddy Quicksall
> Cc: ips@ece.cmu.edu; owner-ips@ece.cmu.edu; pat_thaler@agilent.com
> Subject: RE: iSCSI: changing MaxPDUDataLength
>
>
> That is not completely accurate.
> The only problem is when PDU size decreases and then SNACK must be
> for all data.
> Target can also keep a mapping of numbers/to offsets (the list
should
> be small and if it gets long ask for ack (A-bit).
>
> Julo
>
> Eddy Quicksall
> <eddy_quicksall@ivivity.com> To:
> Sent by: owner-ips@ece.cmu.edu pat_thaler@agilent.com
> cc: ips@ece.cmu.edu
> Subject: RE: iSCSI:
> 06/08/2002 10:54 PM changing MaxPDUDataLength
> Please respond to Eddy Quicksall
>
>
>
>
>
>
>
> Thanks,
>
> As a target, I won't be able to let it change until all of the
> outstanding
> commands are finished (running with ErrorRecoveryLevel>=1). This is
> because
> I must use the PDU size to compute the offset from a SNACK's
> BegRun/RunLength.
>
> So, I plan to not give the text response for a MaxPDURecvDataLength
> in FFP
> until I get back an ExpStatSN == next StatSN.
>
> This will cause a delay of unknown time before the PDU size can
> actually
> change ... do you see any problem with this?
>
> Eddy
>
> -----Original Message-----
> From: pat_thaler@agilent.com [mailto:pat_thaler@agilent.com]
> Sent: Friday, June 07, 2002 1:13 PM
> To: eddy_quicksall@ivivity.com; ips@ece.cmu.edu
> Subject: RE: iSCSI: changing MaxPDUDataLength
>
>
> Eddy,
>
> If one uses a message sync and steering that relys on the transport
> segments
> carrying a full PDU, e.g. TCP ULP Framing Protocol (TUF), then if
the
> path
> MTU changes one would want to change the PDU data length to fit the
> new path
> MTU.
>
> Pat
>
> -----Original Message-----
> From: Eddy Quicksall [mailto:eddy_quicksall@ivivity.com]
> Sent: Wednesday, June 05, 2002 12:24 PM
> To: ips@ece.cmu.edu
> Subject: iSCSI: changing MaxPDUDataLength
>
>
> Does anybody know a case where it is necessary to support a new PDU
> data
> length during full feature phase?
>
> Eddy
> mailto: Eddy_Quicksall@iVivity.com
>
>
>
>
>
>
>
>
>
>
Home Last updated: Tue Jun 11 21:18:44 2002 10676 messages in chronological order |