Jonathan Larmour wrote: > [..] > 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.
As you write below, I think a diff between original and current payload of 255 only may lead to problems... (even if not with TCP options, which _may_ be longer as 255 even if we don't support them). I thought about adding an extra payload pointer after the struct PBUF_REF which only would have to make the PBUF_REF/ROM specific pool elements larger. Also, only pbuf.c would have to know about PBUF_REF structs being larger than the other ones. I think that would be less invasive to the rest of the code. Simon -- GMX Download-Spiele: Preizsturz! Alle Puzzle-Spiele Deluxe über 60% billiger. http://games.entertainment.gmx.net/de/entertainment/games/download/puzzle/index.html _______________________________________________ lwip-users mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/lwip-users
