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

[David Haas]

Right now the assumption is that the payload pointer of a PBUF_ROM or 
PBUF_REF buffer is immutable. I don't think this breaks anything. No one 
should be using PBUF_ROM or PBUF_REF on input to the stack. The netif 
driver on input should be using PBUF_POOL or PBUF_RAM. IMHO users on 
high-performance networks should use PBUF_POOL buffers and dma directly 
into the payload portion of the buffer. It's interesting that we have a 
differing opinion on what PBUF_REF buffers are for. Perhaps we should 
rethink how they are used, but my assumption was that they were only for 
"output" use.

But, I do agree with you for a different reason. I think pbuf_header() 
should take care of any necessary allocation of a new header pbuf and 
then return a pointer to the new chain. The call wants to change the 
payload pointer, it should not make any difference how that gets 
accomplished.

But, I would be afraid to make this change right now. I am not sure what 
else it would break, since it would require changing the callers too. I 
think we should just try to put this pbuf stuff back together right now 
and come up with some stability.

Frankly, my future proposal would be to vastly simplify the whole pbuf 
system by only having two types: PBUF_REF and PBUF_POOL. I think 
PBUF_RAM is far too slow and I don't really know why you would want to 
use PBUF_ROM. I think you could use PBUF_REF instead. I think PBUF_REF 
can only be used on the output side (for zero copy).

David.


Kieran Mansley wrote:

> 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?
> >    
>
> 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
>
>
>
> _______________________________________________
> lwip-members mailing list
> address@hidden
> http://mail.nongnu.org/mailman/listinfo/lwip-members
>
>
>