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

[Jonathan Larmour]

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.

Well it can work, it just makes assumptions about code correctness. But it 
is potentially ok to assume people can write valid code!

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

There is task 7896 for it.

Jifl
--
eCosCentric Limited      http://www.eCosCentric.com/     The eCos experts
Barnwell House, Barnwell Drive, Cambridge, UK.       Tel: +44 1223 245571
Registered in England and Wales: Reg No 4422071.
------["The best things in life aren't things."]------      Opinions==mine