Re: iSCSI : Review Feedback on iSCSI Rev 06

[Santosh Rao <santoshr@cup.hp.com>]

Stephen Bailey wrote:
> 
> Santosh,
> 
> > What I was pointing out was that this upper limit needs to be lower than
> > DataPDULength, failing which fragmentation can occur.
> 
> I see what you're saying now, but I don't agree that the iSCSI spec
> requires this fragmentation.  Data PDUs are not NOP, Text or
> Login[Response] PDUs.  The DataPDULength limit applies only to data
> PDU length (or, we should change the name to PDULength).

Steph,

I've asked this question a long time back on whether DataPDULength
controls the length of all Data PDUs or only the Data PDUs and have'nt
heard a definitive answer on this yet.

If it controls the length of all Data PDUs, it must be re-named to
MaxPDULength. If it does not control the length of all PDUs, then, a
seperate Max PDU Length must be negotiated for all the non-scsi PDUs.
(text, login, nop). 



> The most important point to make is that both the initiator and the
> target be able to control the total size of any PDU sequence received
> (therefore, sent) during an operational session.

Agreed. 


<snip snip>

> 
> Do people actually use GID_FT?  It doesn't seem wise.  I always used
> GA_NXT, and it seemed that all the other FCP implementors I asked did
> as well (it's been a while).

Well, you've just met your first GID_FT implementor in that case. It
saves us a lot of on-the-wire traffic by replacing 'n' GA_NXTs with a
single GID_FT as long as we can handle the buffer allocation [which is
ok with us].

In any case, that's a separate discussion... :}

Regards,
Santosh
begin:vcard 
n:Rao;Santosh 
tel;work:408-447-3751
x-mozilla-html:FALSE
org:Hewlett Packard, Cupertino.;SISL
adr:;;19420, Homestead Road, M\S 43LN,	;Cupertino.;CA.;95014.;USA.
version:2.1
email;internet:santoshr@cup.hp.com
title:Software Design Engineer
x-mozilla-cpt:;21088
fn:Santosh Rao
end:vcard