Simon Goldschmidt wrote: > 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).
Or we could decrease the ref count _and_ merge the flags and type field into a single u8_t, and free up a u16_t, which gives us a much better offset. > 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. That might be a very promising idea. Best so far I think. Jifl -- 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. ------["Si fractum non sit, noli id reficere"]------ Opinions==mine _______________________________________________ lwip-users mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/lwip-users
