Re: MaxRecvPDULength question

[Luben Tuikov <luben@splentec.com>]

Paul Koning wrote:
> 
> I can't quite figure out what you're after, but it doesn't sound
> good.

:-)

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.

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_.
 
> 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.

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.

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

No, not proposing this.

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

-- 
Luben