[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: Mon, 10 Nov 2008 14:29:29 +0000
User-agent: Thunderbird (X11/20070530)

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.

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

reply via email to

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