[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Ed Sutter
Subject: Re: [lwip-users] p->payload == iphdr failed...
Date: Sat, 08 Nov 2008 15:58:37 -0500
User-agent: Thunderbird (Windows/20080914)

Jonathan Larmour wrote:
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.

Unless I hear from one of you guys indicating that this is a problem,
I'm going to try adding a member to the pbuf header to store the base
address of the buffer.
Thanks again,

reply via email to

[Prev in Thread] Current Thread [Next in Thread]