Subject: Re: MaxRecvPDULength question

From: Luben Tuikov <[email-masked]>
Date: Tue, 21 May 2002 17:33:48 -0400

"THALER,PAT (A-Roseville,ex1)" wrote:
> 
> 
> BTW your email seemed to imply that MaxRecvPDULength is a power of two.

My computer says: 2^13 = 8192, which in turn is equal to the
default value of MaxRecvPDULength.

> Currently, MaxRecvPDULength is not limited to be a power of two.
> (I recall a discussion about that and I think the concensus was
> consistant with the current draft.)

True, but if it changes after login, I can deal with it.
I.e. I'd not allocate more memory if it shrinks,
and I'll increase it by PAGE_SIZE if it grows.

Anyway, this was just a suggestion, not so important.

I was more interested in getting an authoritative answer
on the ``Login Request Error'' thread's last message.

-- 
Luben

---

From: "THALER,PAT (A-Roseville,ex1)" <[email-masked]>
Date: Tue, 21 May 2002 15:20:36 -0600

Luben,

I agree with Paul that the suggestion doesn't sound good. I don't understand your perspective since in my view we are generally moving around the data rather than the whole PDU and it is very useful to specify the maximum length for the data field of the PDU. 

Further, there may be headers beyond the BHS and it would complicate implementation to have to know what headers are being sent in order to derive the limit on the data segment length for a PDU. 

The key name MaxRecvPDULength is a bit misleading as it seems to imply the whole PDU and Paul's suggestion of MaxRecvDataLength isn't much better as it doesn't differentiate between the data length of a PDU or a burst. Going into picky mode, it also isn't clear why this is a length while bursts have a size. MaxRecvDataSegmentSize or MaxRecvDataSegSize would be more precise, but I'm not sure it is worth tweaking the name at this point.

BTW your email seemed to imply that MaxRecvPDULength is a power of two. Currently, MaxRecvPDULength is not limited to be a power of two. (I recall a discussion about that and I think the concensus was consistant with the current draft.)

Pat

-----Original Message-----
From: Paul Koning [mailto:[email-masked]]
Sent: Tuesday, May 21, 2002 11:54 AM
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: MaxRecvPDULength question

Excerpt of message (sent 21 May 2002) by Luben Tuikov:
> The key name ``MaxRecvPDULength'' doesn't imply
> <MaxRecvDataLength>? Why is it considered as
> such then?
> 
> I suggest that ``MaxRecvPDULength'' be set to mean
> the maximum PDU length, NOT the maximum _data_ length.
> 
> Reason: It is _faster_ to get the PDU off the the TCP
> data stack in _one_ (system) call, rather than two (system) calls.
> This _would_ improve implementaions, more so for user-space such.
> 
> But lets still keep the size of the PDU a power of 2.
> (This would imply that the non-existent MaxRecvDataLength
> to MaxRecvPDULength - 48.)
> 
> Comments?

I can't quite figure out what you're after, but it doesn't sound
good. 

There are two parameters of interest: the size of the entire iSCSI
PDU, and the size of the data portion of the PDU.  

It doesn't matter a whole lot which of the two you specify, because
the difference is simply the iSCSI header size.  I find it useful to
think in terms of the data length, because that relates to alignment
of data going into the storage machinery, etc. 

Are you proposing to rename the key so its name is
"MaxRecvDataLength"?  Yes, that would be more accurate, but why bother
at this point?

The overall PDU size current is NOT a power of two given the current
defaults, and should not be, because that would make the data length a
weird value.

As for your comment about 1 vs. 2 system calls, I don't understand
what system calls you're talking about.  The performance argument is
not meaningful because it may only be done once per system boot, or at
the very worst once per login.