lwIP - A Lightweight TCP/IP stack - Tasks: task #6831, Integrate pbuf pool into memp...
You are not allowed to post comments on this tracker with your current authentication level.
task #6831: Integrate pbuf pool into memp pools to reduce code size
Submitter: | Simon Goldschmidt <goldsimon> | ||
Submitted: | Sun 29 Apr 2007 10:57:23 AM UTC | ||
Category: | None | Should Start On: | Sun 29 Apr 2007 12:00:00 AM UTC |
Should be Finished on: | Sun 29 Apr 2007 12:00:00 AM UTC | Priority: | 1 - Later |
Status: | Done | Privacy: | Public |
Assigned to: | None | Percent Complete: | 0% |
Open/Closed: | Closed | Planned Release: | None |
Effort: | 0.00 |
Jump to the original submission
Wed 16 May 2007 02:15:22 PM UTC, comment #12: |
Simon Goldschmidt <goldsimon> |
Wed 16 May 2007 02:00:27 PM UTC, comment #11: PBUF_STATS can also be remove from opt.h. |
Frédéric Bernon <fbernon> |
Wed 16 May 2007 01:56:46 PM UTC, comment #10: Sorry to disturb,
|
Frédéric Bernon <fbernon> |
Wed 16 May 2007 01:50:28 PM UTC, comment #9: You're right. I think I'm blind, I did not see that comment ;-)
|
Simon Goldschmidt <goldsimon> |
Wed 16 May 2007 12:45:09 PM UTC, comment #8: About the use of memp to replace pbuf_pool_alloc, I think you have to update "stats" feature (useful to tune lwIP values). Remember the comment in memp.h :
|
Frédéric Bernon <fbernon> |
Sun 13 May 2007 06:17:20 PM UTC, comment #7: OK, removing the option and the old code. If there are errors, it's still accesible through old CVS version, anyway. |
Simon Goldschmidt <goldsimon> |
Sun 13 May 2007 06:03:23 PM UTC, comment #6: With a lot of proposed re-implementations in the last while, there is usually some performance improvement, but at the expense of memory. Hence options. I don't think that's the case here though.
|
Jonathan Larmour <jifl> |
Sun 13 May 2007 05:54:20 PM UTC, comment #5: No, you're right. I wanted to leave the old code in the files for a while. Do you propose to remove the option from opt.h and remove all the old code? Personally, I think this would be the best solution, I thought I would be the only one... |
Simon Goldschmidt <goldsimon> |
Sun 13 May 2007 04:23:32 PM UTC, comment #4: I might be missing something... is there any merit in the old code at all now?
|
Jonathan Larmour <jifl> |
Sun 13 May 2007 04:17:10 PM UTC, comment #3: I've checked this in: added a new option PBUF_POOL_USES_MEMP in opt.h. If this is =1, a new memp pool will be used for pbufs, if =0 (default for now), the old code is active.
|
Simon Goldschmidt <goldsimon> |
Sun 29 Apr 2007 04:26:50 PM UTC, comment #2:
|
Simon Goldschmidt <goldsimon> |
Sun 29 Apr 2007 11:20:07 AM UTC, comment #1: I think it would be a good idea. I assume all you mean is effectively replacing pbuf_pool_alloc() with a call to memp_malloc with a new MEMP type? The differences between these before were mostly in the area of !SYS_LIGHTWEIGHT_PROT code.
|
Jonathan Larmour <jifl> |
Sun 29 Apr 2007 10:57:23 AM UTC, original submission:
Are there any arguments against including the PBUF_POOL pbufs into memp.c instead of having a second pool implementation in pbuf.c?
|
Simon Goldschmidt <goldsimon> |
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.
Follow 2 latest changes.
Date | Changed by | Updated Field | Previous Value | => | Replaced by |
---|---|---|---|---|---|
2007-05-13 | goldsimon | Status | None | Done | |
Open/Closed | Open | Closed |
Powered by Savane 3.13-4b48.
Corresponding source code
msg_in.c: Since I don't really know what the code does there, I simply remove those lines, since they already did nothing if PBUF_STATS was set to 0, although this leaves an empty if statement.
I've also removed it from opt.h. I only hope I did not oversee yet another corner...