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

[Ed Sutter]

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

Doesn't either case have a problem with freeing the packet?  If I assign
pbufs directly to my DMA based ethernet driver, then what mechanism would
I use in LWIP to release the buffer?  Is there a callback or something that
would be used when lwip is done with the buffer?  If there is, then wouldn't
that same callback be useable in my driver?
Ed