Re: MaxRecvPDULength question

[Paul Koning <ni1d@arrl.net>]

Excerpt of message (sent 21 May 2002) by Luben Tuikov:
> 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.

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