[lwip-users] Re: [lwip-members] pbuf_header() now does not work for PBUF_REF and PBUF_ROM

[Leon Woestenberg]

Hello David, Kieran, others,

> On Mon, 31 Mar 2003, David Haas wrote:
>
> > Leon,
> >
> > The current version of pbuf_header() is broken for PBUF_REF and
> > PBUF_ROM. It should fail and not change the payload pointer. Instead it
> > is returning 0 and changing the payload pointer. Would you mind if I fix
> > it?
>
OK, it is indeed broken because the stack may never assume it can safely
allocate header space before the payload pointer.

However, Kieran's argument is valid that the header may be hidden (moving
the payload pointer upwards). I will change the code to allow increasing the
pbuf payload pointer.

> I'm not so sure this is broken, or rather that your change would be less
> broken!  The stack will fail in a big heap if pbuf_header doesn't do what
> it expects.  In particular when packets are received pbuf_header is used
> with a negative value to hide the (for example) ip header from the tcp
> stack and so on.  This is completely valid for both PBUF_REF and PBUF_ROM,
> and I would envisage people using PBUF_REF to receive packets on high
> performance networks.  Perhaps we should change it so that it only
> succeeds if it moves to within the boundaries of the original pbuf?
>
> Kieran
>
This is exactly what Marc Wells has done with his PBUF_EXT, which seems
exactly the thing we are talking about now. I think moving in that direction
is
excellent, as it generalizes the way the payload is refered to, paving way
for
the optimized pbuf pool idea.

Please read Marc's email on the users list on 21/3/2003 called
"Zero copy receive buffers".

I quote:
"The new 'buffer' member of the pbuf
structure is set to the address of the beginning
of the payload section of RAM and POOL type pbufs.
This value is used by the pbuf_header function for
error checking."

Regards,

Leon.