RE: [lwip-devel] IP fragmentation

[Goldschmidt Simon]

> 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?).

> 
> 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.
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.

> 
> >> 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.

Agree again. Do you implment it? ;-)