Subject: MaxRecvPDULength question

From: Luben Tuikov <[email-masked]>
Date: Tue, 21 May 2002 13:50:25 -0400

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?

-- 
Luben

---

From: Paul Koning <[email-masked]>
Date: Tue, 21 May 2002 14:53:54 -0400

> to MaxRecvPDULength - 48.)

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.

---

From: Bill Studenmund <[email-masked]>
Date: Tue, 21 May 2002 13:55:14 -0700 (PDT)

> > This _would_ improve implementaions, more so for user-space such.

Unfortunately I don't think we can do that. The problem is that we still
would need to know how much data were sent. Mainly as we don't HAVE to
send the maximum amount of data. :-)

> of data going into the storage machinery, etc.

I agree.

> the very worst once per login.

Luben was wanting to make it so the WHOLE PDU (header and data both) could
be read with one system call.

Take care,

Bill

---

From: Paul Koning <[email-masked]>
Date: Tue, 21 May 2002 17:40:38 -0400

Excerpt of message (sent 21 May 2002) by Luben Tuikov:
> Paul Koning wrote:
> :-)
> I'd like to use the slab cache allocator (lookaside cache, kernel space)
> to allocate memory for max PDU, rather than calling *alloc().
> This is fast, and reliable, etc, etc compared to *alloc().
> 
> I'd also like a max PDU to fit nicely into memory, i.e. at
> page size boundaries, being a multiple of PAGE_SIZE.
> This would also improve performance.
> 
> Currently, you'd have 2 buffers, one for PDU (48 bytes)
> and another for data (MaxRecvPDULength), and
> you'd get both data with time separated system/kernel
> function calls -- one for 48 bytes and another
> for the rest of the data.

I suppose it's possible to construct an implementation like that, but
why would you do that?  (By the way, I assume you meant "PDU header
(48 bytes)".)

You know the max payload size; you know the max header size; given
those you know the max PDU size.  You can then allocate PDU buffers
that big, and you can select the receive offset so the payload starts
at a convenient boundary -- given that you know most headers will be
48 bytes long.

There's nothing in the current spec that forces you to receive a PDU
in two pieces.

      paul

---

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

:-)

Consider that this is a packet based proto on top
of stream based one, on top of ...

Anyway, when we get data we get the whole thing at once
and there is NO point in making 2 calls to get the whole thing.

If an implementation is in user-space, then forget it performance
wise. Mine is in kernel space and I'd like to make it _faster_.
 
> of data going into the storage machinery, etc.

But, if the data spills, then it has to be assembled anyway
before being passed down/up the device driver/ULP,
so this will not be of much significance.

If it doesn't spill, then we're ok, just pass it to whoever
is interested.

> "MaxRecvDataLength"?  Yes, that would be more accurate, but why bother

No, not proposing this.

I'm proposing, that ``MaxRecvPDULength'' mean just that!

-- 
Luben

---

From: Martins Krikis <[email-masked]>
Date: Wed, 22 May 2002 12:19:38 -0700 (PDT)

> "MaxRecvDataLength"?  Yes, that would be more

Because it would be more accurate!

I personally don't mind changes in the draft that
make it clearer but require me to change one string
constant.

  Martins Krikis, Intel Corp.

__________________________________________________
Do You Yahoo!?
LAUNCH - Your Yahoo! Music Experience
http://launch.yahoo.com