lwip-devel
[Top][All Lists]
Advanced

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

RE: [lwip-devel] IP fragmentation


From: Goldschmidt Simon
Subject: RE: [lwip-devel] IP fragmentation
Date: Fri, 11 May 2007 08:29:44 +0200

> The only thing that bothers me about this solution is that there can
be a
> sizeable chunk of pbufs floating around in limbo waiting for the rest
of
> the fragments to arrive.  This means if a large number of fragments
are
> incomplete at any given moment, say from a very unreliable link or
greatly
> mismatched targets, then the stack could exhaust it's pool of pbufs,
and be
> deadlocked.  I would support a limit on the number of pbufs that can
be
> used for fragmented packets at any one time.  This way, there will
always
> be pbufs in reserve to receive new packets.

This is what I proposed. Then you just have to have enough pbufs in the
pool
so that your pools doesn't get empty. And you could still allocate them
at
startup exchanging them for the received (so that the amount of pbufs in
the
pool stays the same whether you are receiving fragmented IP or not, you
just
statically allocate some of them for ip_reass).


> Then again, maybe the reassembly timer is good enough to protect
against
> this scenario.  Every 3 seconds, or whatever it is set to, it flushes
the
> stale fragments, releasing the previously bound pbufs.

I don't think so. You could still be receiving so much that, after
freeing some
timed out fragments, you immediately run out of pbufs again if you only
have a
timeout for each fragment instead of a maximum count of fragments ...
        
> From reading the above, it sounds like we're trying to decide whether
to go
> with a malloc/memcpy approach to efficiently allocate heap space for
fragments
> as they arrive, or to use the pbufs, which don't require a memcpy, but
aren't
> necessarily as efficient, space-wise.  In some respects it depends on
the
> implementation of the malloc.

I think it's a very simple ifdef: hold the PBUF_POOL (and maybe free
another
on in exchange) or allocate a PBUF_RAM and do some memcpy(), the rest
stays
the same.

> Many embedded OSes use a pool based allocation scheme to handle
fragmentation
> issues, while most general purpose OSes use whatever suits their
fancy. 

That's why I want to eliminate the heap in lwIP (at least as an
option)...


[...]
> If not, then I much prefer the pbuf approach. 

As I said, in my opinion, they are both pbuf approaches... :-)



Simon




reply via email to

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