lwip-devel
[Top][All Lists]
Advanced

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

Re: [lwip-devel] IP fragmentation


From: Jonathan Larmour
Subject: Re: [lwip-devel] IP fragmentation
Date: Wed, 09 May 2007 12:37:32 +0100
User-agent: Thunderbird 1.5.0.10 (X11/20070301)

Goldschmidt Simon wrote:
The main problem I see, as mentioned in that task, is you have to use up a whole PBUF_POOL_BUFSIZE (or even multiple) worth of bytes from the pbuf pool.

Suppose PBUF_POOL_BUFSIZE is 256, and there is an MTU somewhere between this host and the remote peer of 576 - not uncommon given that's the internet standard. Then you may waste 192 bytes per frag. Storing a 32K (for example) PDU would take 57 pbufs, with about 11KiB wasted (ignoring pbuf structure overheads).

That is a general pool vs. heap issue. My proposal at least lets
you use the pbuf pool without dead-locking the stack. to use it
or not (e.g. 'wasting' the memory for it or not) would be the
Decision of the developer (and I chose to have mem_malloc() using
pools, which also wastes a lot of RAM). The point is I would like
to be able to chose. That way you can configure lwIP running slow
on small targets or running fast on bigger targets (a marketing
guy would probably say it scales?).

Personally I don't have trouble with things as config options.

Maybe we could copy them into PBUF_RAMs, rather than having a separate buffer. I'm undecided whether that would be worth it.

That would make the ip_frag code a little cleaner, but you could
instead pass pbuf_refs pointing into ip_reassbuf to ip_input, so
either way you would end up copying only once (from the received
PBUF_POOL to ip_reassbuf or to PBUF_RAM), which is better as the
current situation.

You still have to have the dedicated buffer with that approach. At least memory for PBUF_RAMs can be shared with other parts of the system. There is the overhead of the pbuf structure admittedly - probably 16 bytes + possible alignment bytes. Hopefully that is small compared to the fragment size which should be at a minimum 576 bytes. Arguably it could be a footprint increase for some people, but I'm not sure it's enough to be concerned about.

At least you would allow easy switching between single-copy using
PBUF_RAM and zero-copy using PBUF_POOL, which I think would be
a good compromise.

If the config option can be cleanly done, then feel free :).

[path mtu discovery]
Agree again. Do you implment it? ;-)

Heh. I wasn't proposing anyone implementing it right now (unless they want to :-)). It was just a throwaway comment.

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.
------["The best things in life aren't things."]------      Opinions==mine




reply via email to

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