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

[Jonathan Larmour]

address@hidden wrote:
> Ed Sutter wrote:
>
> > Jonathan Larmour wrote:
> >  
> > > 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.
>
> I guess that will work fine and it's also the solution I had in mind, 
> but adding a member to the struct wasn't appreciated: the current size 
> of 16 bytes is really optipmal for most platforms regarding memory 
> alignment (or cache size). Also, adding 4 bytes to each pbuf can mean a 
> crucial amount of additional memory on some low-memory platforms!

Especially taking into account alignment requirements - it's particularly 
the case for PBUF_POOL pbufs anyway since at present the start of the pbuf 
data comes straight after the struct pbuf and will usually need alignment, 
and the struct pbuf is used for all types obviously.

It's possible to come up with a solution despite this. For example, the 
ref count is currently 16-bit which is probably overkill. Or the type and 
flags field could be merged[1]. I think I'd prefer the former - I can't 
imagine more than 255 references to a single pbuf. Even with a pbuf chain 
with only 128 byte pbufs, that would still be equivalent to nearly 32Kbyte 
jumbo frames (and the obvious solution if somehow this was likely would be 
to use larger pbufs!). Anyway, with a u8_t of extra space, you can't store 
the base address, but you can store the offset from the payload pointer to 
the real start of the packet - pbuf_header could adjust it every time.

This would probably be a step towards solving task 7896 as well too, since 
 I've been thinking that one of the problems to be solved there is 
dissociating PBUF_POOL pbuf headers from their payloads. After all, in 
some cases the packet buffer data might be in a special region which 
cannot also have a struct pbuf before it; and there may be other 
hardware-specific data structures around too.

The only concern I have would be TCP options - would we use pbuf_header to 
move past the tcp header including options? And if so, those can be larger 
than 256 bytes presumably.

Jifl
[1] This is the way it used to be (although as a u16_t), but it can always 
be undone.
--
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