tasklwIP - 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: 

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

Simon Goldschmidt <goldsimon>
Group administrator
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>
Group Member
Wed 16 May 2007 01:56:46 PM UTC, comment #10: 

Sorry to disturb,

But in msg_in.c, in snmp_ok_response, there is a LWIP_DEBUF using lwip_stats.pbuf:

    /* serious memory problem, can't return tooBig */
#if PBUF_STATS
    LWIP_DEBUGF(SNMP_MSG_DEBUG, ("snmp_msg_event pbufs.used = %"U16_F"\n",lwip_stats.pbuf.used));
#endif

Frédéric Bernon <fbernon>
Group Member
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 ;-)

Thanks for reminding me, I've already checked it in.

Simon Goldschmidt <goldsimon>
Group administrator
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 :

/* If you change this enum, think to update memp_names in stats_display (stats.c) */

In current CVS, it's not done.

Frédéric Bernon <fbernon>
Group Member
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>
Group administrator
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>
Group Member
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>
Group administrator
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>
Group Member
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.

Closing this as done.

Simon Goldschmidt <goldsimon>
Group administrator
Sun 29 Apr 2007 04:26:50 PM UTC, comment #2: 


>I assume all you mean is effectively replacing pbuf_pool_alloc() with a call to memp_malloc with a new MEMP type?


That's exactly what I meant. The only thing more to do would be to set p->flags after allocating the pbuf. The rest should be the same and we would save some bytes in code size.

Simon Goldschmidt <goldsimon>
Group administrator
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.

If you meant anything more than replacing pbuf_pool_alloc, it probably wouldn't save much since most of the fiddling done by pbuf.c for PBUF_POOL allocations is pbuf-specific, and hence would mean just bringing that same code into memp.c.

Jonathan Larmour <jifl>
Group Member
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?

I think including PBUF_POOLs into memp.c could reduce code size and wouldn't be much slower.

Simon Goldschmidt <goldsimon>
Group administrator

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by fbernon (Posted a comment)
  • -email is unavailable- added by jifl (Posted a comment)
  • -email is unavailable- added by goldsimon (Submitted the item)
  •  

    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 StatusNone Done
        Open/ClosedOpen Closed

    Back to the top

    Powered by Savane 3.13-4b48.
    Corresponding source code