[Top][All Lists]

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

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

From: Jonathan Larmour
Subject: Re: [lwip-users] p->payload == iphdr failed...
Date: Sun, 09 Nov 2008 22:01:58 +0000
User-agent: Mozilla Thunderbird 1.0.8-1.1.fc3.4.legacy (X11/20060515)

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.

[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

reply via email to

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