[EMAIL PROTECTED] 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
_______________________________________________
lwip-users mailing list
[email protected]
http://lists.nongnu.org/mailman/listinfo/lwip-users
