[Top][All Lists]
[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:05:33 +0100 |
User-agent: |
Thunderbird 1.5.0.10 (X11/20070301) |
Goldschmidt Simon wrote:
What also disturbs me is that,
because there is only one reassembly-buffer, you can only receive
fragmented IP-packets from one host at a time. That's because I
didn't
enable IP_REASSEMBLY...
Or am I wrong and this would never happen??
This is correct and intentional - more frags to reassemble
means more memory, it's as simple as that.
If fragmented packets would be temporarily stored in their corresponding
pbuf instead of copying them into reassbuf, you would waste less memory
since you don't have to provide the maximum memory all the time using
only pbuf memory if you really have something to reassemble. And the
amount of pbufs being in the reassembly buffer could easily be
configured.
(see task #6861 for my ideas about that)
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).
Maybe we could copy them into PBUF_RAMs, rather than having a separate
buffer. I'm undecided whether that would be worth it.
You should try and
avoid getting fragmented packets in the first place!
Of course if lwIP could implement path MTU discovery, it
could keep up its side of the bargain.
Agree, but isn't reassembly the wrong side for that?
That's what I meant be keeping up its side of the bargain. If you want to
avoid fragmentation, you have to avoid sending packets larger than any MTU.
So if lwIP doesn't want fragmented packets, it should equally be trying to
avoid sending them. More relevantly, if an lwIP device was talking to an
lwIP device, then unless they've already been configured with a sensible
MSS (or MTU) they may always fragment. If _everyone_ implements path MTU
discovery, fragmentation is not needed. For TCP anyway.
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
- [lwip-devel] IP fragmentation, Thomas Taranowski, 2007/05/08
- RE: [lwip-devel] IP fragmentation, Goldschmidt Simon, 2007/05/09
- Re: [lwip-devel] IP fragmentation, Jonathan Larmour, 2007/05/09
- RE: [lwip-devel] IP fragmentation, Goldschmidt Simon, 2007/05/09
- Re: [lwip-devel] IP fragmentation,
Jonathan Larmour <=
- RE: [lwip-devel] IP fragmentation, Goldschmidt Simon, 2007/05/09
- Re: [lwip-devel] IP fragmentation, Jonathan Larmour, 2007/05/09
- Re: [lwip-devel] IP fragmentation, Thomas Taranowski, 2007/05/10
- RE: [lwip-devel] IP fragmentation, Goldschmidt Simon, 2007/05/11
- [lwip-devel] additional/optional protocols, Decker, Paul, 2007/05/23
- Re: [lwip-devel] additional/optional protocols, Kieran Mansley, 2007/05/24