Re: [lwip-users] p->payload == iphdr failed...

[Ed Sutter]

address@hidden wrote:
> Ed Sutter wrote:
> > Ok, I see what you're talking about in pbuf_header().  I don't know 
> > the history
> > of the code to comment on whether or not the change should be in the 
> > master
> > code base; but it would seem to me that if this is forcing a driver to 
> > use
> > the memcpy loop to build the pbuf chain, then it would be a good 
> > improvement.
> >   
> The reason pbuf_header can't expand to the front is that it doesn't know 
> where the memory area that the PBUF_REF points to starts. While 
> shrinking works as long as p->len is > 0, expanding to the front doesn't 
> work without another pointer in the pbuf struct that tells us the 
> original ->payload pointer.

Why is it a problem to just add another member to the structure that keeps
track of the start of the buffer?  I'll try this out if that's the only issue
(I'm guessing there must be more to it).

> For this reason, it is not a good thing to give this 'feature' to 
> everyone as this could very easily lead to memory corruption.
>
> The way to prevent memcpy is to allocate a PBUF_POOL (of the maximum 
> size) and pass the ->payload pointer to the MAC which can store the 
> receive data directly to that location. This method has some 
> disadvantages though: a) with most MACs, you cannot use chained pbufs 
> for receiving and b) you cannot use this method with MACs that have 
> internal receive buffers.

The strategy that I use in my code is one that is independent of the driver.
This is the LWIP-based server stuff I'm using as a demo application that
runs on uMon's packet API.  Seems to me that its a reasonable thing to
be able to do.

> Just so you know: changing this _is_ on the to-do-list somewhere, but I 
> think don't even know whether there is a feature-request for this 
> somewhere...

I'll look into this further.
Thanks
Ed