lwIP - A Lightweight TCP/IP stack - Bugs: bug #3031, Implement a new fully pool-based...
You are not allowed to post comments on this tracker with your current authentication level.
bug #3031: Implement a new fully pool-based pbuf implementation.
Submitter: | Leon Woestenberg <likewise> | ||
Submitted: | Tue 01 Apr 2003 11:44:15 AM UTC | ||
Category: | pbufs | Severity: | 2 - Minor |
Item Group: | Feature Request | Status: | None |
Privacy: | Public | Assigned to: | None |
Open/Closed: | Open | Planned Release: | None |
lwIP version: | None |
Jump to the original submission
Thu 27 Mar 2008 09:57:28 PM UTC, comment #29: |
Simon Goldschmidt <goldsimon>![]() |
Tue 25 Mar 2008 09:19:06 PM UTC, comment #28: As nice as this idea is, it's a little off-topic in this thread: The original idea of this 'bug' has already been implemented: PBUF_RAM using pools. This can be achieved by the new memp_std.h file.
|
Simon Goldschmidt <goldsimon>![]() |
Tue 25 Mar 2008 01:50:04 PM UTC, comment #27: I think the mem_malloc in dhcp can be easily removed by creating a netif_dhcp which has a netif and definition of struct dhcp added. The allocation looks to be a one time event but I have not dug that deep into the code. In dhcp_inform, it's allocated and freed - maybe that struct dhcp can be stack based?
|
Bill Auerbach <billauerbach> |
Tue 25 Mar 2008 01:38:41 PM UTC, comment #26: Would anyone like to summarise what remains to be done to close this bug. Now that 1.3.0 has been made we should perhaps reconsider this. I feel like this should really be moved to a task. |
Kieran Mansley <kieranm>![]() |
Thu 09 Aug 2007 02:22:47 PM UTC, comment #25:
|
Jonathan Larmour <jifl>![]() |
Thu 09 Aug 2007 02:01:40 PM UTC, comment #24:
|
Simon Goldschmidt <goldsimon>![]() |
Thu 26 Jul 2007 03:12:09 PM UTC, comment #23:
|
Jonathan Larmour <jifl>![]() |
Thu 26 Jul 2007 02:43:53 PM UTC, comment #22: Ah, OK. But there are two problems with counting the segments:
|
Simon Goldschmidt <goldsimon>![]() |
Thu 26 Jul 2007 02:38:27 PM UTC, comment #21:
|
Jonathan Larmour <jifl>![]() |
Tue 24 Jul 2007 11:03:20 AM UTC, comment #20:
|
Simon Goldschmidt <goldsimon>![]() |
Fri 20 Jul 2007 06:43:17 PM UTC, comment #19: Re comment #17: Only raw API applications would be affected. anything using the socket API or netbuf_* functions of the sequential API would be fine. But even then, I think it's always been the case that we should have been able to handle chained PBUF_RAMs, and the issue in tcp_enqueue falls into the category of a bug, not a feature ;).
|
Jonathan Larmour <jifl>![]() |
Tue 03 Jul 2007 08:30:48 PM UTC, comment #18: I've added the asserts for a start. |
Simon Goldschmidt <goldsimon>![]() |
Mon 25 Jun 2007 01:23:46 PM UTC, comment #17:
|
Simon Goldschmidt <goldsimon>![]() |
Mon 25 Jun 2007 01:20:37 PM UTC, comment #16:
|
Simon Goldschmidt <goldsimon>![]() |
Mon 25 Jun 2007 12:51:34 PM UTC, comment #15: I see no reason why we shouldn't allow chained PBUF_RAMs, so the assertions are probably a good idea. However, i don't understand why pbuf_clen() is insufficient to count the length of such a chain.
|
Kieran Mansley <kieranm>![]() |
Sat 23 Jun 2007 03:56:33 PM UTC, comment #14:
|
Simon Goldschmidt <goldsimon>![]() |
Sat 23 Jun 2007 01:29:23 PM UTC, comment #13: Some changes are necessary to make tcp work with chained pbufs:
|
Simon Goldschmidt <goldsimon>![]() |
Fri 22 Jun 2007 09:41:54 PM UTC, comment #12: ... and it is a problem! At least for TCP, the other parts have such low requirements that small PBUF_POOL pbufs are big enough.
|
Simon Goldschmidt <goldsimon>![]() |
Tue 22 May 2007 11:14:59 AM UTC, comment #11: What I meant was maybe there are some corner cases when a PBUF_RAM is allocated and it not fails that the code allocating it expects it to be in one piece. The parts of the stack that can deal with PBUF_REF or PBUF_POOL can cope with chains, of course! |
Simon Goldschmidt <goldsimon>![]() |
Tue 22 May 2007 11:12:42 AM UTC, comment #10: I think the stack should already be handling pbuf chains. For transmission, the netconn API pretty much encourages it with use of netbuf_chain, and this function would be well used.
|
Jonathan Larmour <jifl>![]() |
Tue 22 May 2007 07:08:37 AM UTC, comment #9: [I'm working on a mem to memp implementation (that is written in ANSI C; and I'm short of time at the moment so it could take a while).]
|
Simon Goldschmidt <goldsimon>![]() |
Thu 12 Apr 2007 07:18:24 AM UTC, comment #8:
|
Atte Kojo <kojo> |
Thu 12 Apr 2007 06:56:44 AM UTC, comment #7: Oh, I forgot to comment about the buddy allocator. It was me you mentioned that one to, some half a year ago... But I must say I'm not really satisfied with that. While it gives less fragmentation than our current heap implementation, it's still worse than our pool-implementation. And since we are not that low on RAM, we've chosen to stay with our pools ;-) |
Simon Goldschmidt <goldsimon>![]() |
Thu 12 Apr 2007 06:26:19 AM UTC, comment #6:
|
Simon Goldschmidt <goldsimon>![]() |
Wed 11 Apr 2007 10:37:58 PM UTC, comment #5: Yes, I was slightly more concerned about Atte's suggestion of making everything come from pools.
|
Jonathan Larmour <jifl>![]() |
Wed 11 Apr 2007 06:20:27 PM UTC, comment #4:
-> setting this to minor severity! |
Simon Goldschmidt <goldsimon>![]() |
Wed 11 Apr 2007 05:17:11 PM UTC, comment #3: By having multiple separate pools, you increase overall RAM memory use - which is far more of an issue than code footprint for most embedded systems. It's inevitable you will sometimes run out of memory in one pool while still having memory in another, which is wasteful. And pools of fixed chunks which don't fit the allocations will intrinsically have waste. Statistical analysis may reduce some but not all of the overhead, and only really helps "average" operation.
|
Jonathan Larmour <jifl>![]() |
Fri 09 Mar 2007 01:58:43 PM UTC, comment #2: I'm also in favor of a general pool allocator. But the current memp implementation is unnecessarily complex. It reserves separate pools for all possible object types that can be allocated, thus wasting a lot of space and time. And on top of that pbuf module has its own pool.
|
Atte Kojo <kojo> |
Tue 06 Mar 2007 08:27:08 AM UTC, comment #1: This one would be of great interest for me, as I think embedded systems running for a long time should not have a heap if memory is allocated ADN deallocated often with different sizes. (And our devices have to run a looong time, ~30 years is our goal)
|
Simon Goldschmidt <goldsimon>![]() |
Tue 01 Apr 2003 11:44:15 AM UTC, original submission:
Experience has shown a flexible pool pbuf system can replace all current pbuf types. A pool with 2^n sized pools, with some special sizes added (such as sizeof(struct pbuf), sizeof(struct pbuf) + IP_HLEN + ETH_HLEN) has high potential in realizing a low-latency high performance buffering system for packet representation.
|
Leon Woestenberg <likewise>![]() |
No files currently attached
Depends on the following items: None found
Items that depend on this one: None found
There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.
Of course the current approach has the downside that MEM_USE_POOLS diverts the whole heap to pools, not only PBUF_RAM. Maybe we should review this... ?