|
From: | Jonathan Larmour |
Subject: | Re: [lwip-users] p->payload == iphdr failed... |
Date: | Sat, 08 Nov 2008 16:05:01 +0000 |
User-agent: | Mozilla Thunderbird 1.0.8-1.1.fc3.4.legacy (X11/20060515) |
Ed Sutter wrote:
Jonathan Larmour wrote:Ed Sutter wrote:Jonathan Larmour wrote:Ah I see in the implementation of pbuf_header, that it can't expand PBUF_REFs to the front. That will be your problem. I think the only reason it doesn't do it is because there's no way to sanity check that it's a valid thing to do.Hmmmm... If I can't use PBUF_RAW/PBUF_REF to allocate the pbuf, then does that mean I have no choice but to do the loop of memcpy's like this...[snip]Or is there some other way to avoid that copy loop?I think the better answer for you would be to adjust the PBUF_REF case in pbuf_header() to allow PBUF_REF pbufs to be expanded to the front.I'm undecided whether that would be a good change to have in the master code base.Ok, I see what you're talking about in pbuf_header(). I don't know the historyof 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 usethe memcpy loop to build the pbuf chain, then it would be a good improvement.
It might be worth doing, but I'm not sure it's worth doing for that reason. That's an odd driver model to have as there's no obvious way for the packet memory pointed to by the PBUF_REF to be freed.
Anyway, if there is no other better way to do this I suppose I'll just stick with it (don't have time to look into pbuf_header() at the moment). I guess this must be what everyone does (otherwise they would be running into the sameproblem I'm running into), right?
Either you copy the data, or you allocate PBUF_POOL pbufs and make sure the hardware/driver copies directly into those, rather than into an intermediate buffer.
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
[Prev in Thread] | Current Thread | [Next in Thread] |