lwip-devel
[Top][All Lists]
Advanced

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

[lwip-devel] [patch #5863] Use of mem_malloc should be reduced


From: Simon Goldschmidt
Subject: [lwip-devel] [patch #5863] Use of mem_malloc should be reduced
Date: Wed, 11 Apr 2007 10:01:58 +0000
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.1.2) Gecko/20070219 Firefox/2.0.0.2

URL:
  <http://savannah.nongnu.org/patch/?5863>

                 Summary: Use of mem_malloc should be reduced
                 Project: lwIP - A Lightweight TCP/IP stack
            Submitted by: goldsimon
            Submitted on: Mittwoch 11.04.2007 um 10:01
                Category: None
                Priority: 3 - Low
                  Status: None
                 Privacy: Public
             Assigned to: None
        Originator Email: 
             Open/Closed: Open
         Discussion Lock: Any

    _______________________________________________________

Details:

In my opinion, to prevent memory fragmentation, we should try to reduce the
amount of calls to mem_malloc() from different modules. My goal would be that
mem_malloc() is (for the stack, not the application) only called from pbuf.c.
That way, when porting the stack (or later, as a compile option), you could
easily switch pbuf.c from mem_malloc() to a pool-based
PBUF_RAM-implementation and totally prevent fragmentation.

This change would mainly change 4 modules:
- dhcp.c: I would create a new memp-pool for that
- loopif.c: In my opinion, mem_malloc is not needed here, see comment #4 in
bug #2595
- ethernetif.c: The same here: mem_malloc is not needed: struct ethernetif
only holds the mac address, which is included in struct netif, already!
- SNMP (mib_structs.c/msg_in.c): I would create one or more new mem-pools for
that, size would have to be investigated.

To me, the hardest part seems to be SNMP here. DHCP can easily be switched to
a memp pool since the size of the chunks can be calculated. In msg_in.c, there
are calls like mem_malloc(vb->value_len) or mem_malloc(sizeof(s32_t)*i), which
are harder, but still they can be observed and a pool could be created.




    _______________________________________________________

Reply to this item at:

  <http://savannah.nongnu.org/patch/?5863>

_______________________________________________
  Nachricht geschickt von/durch Savannah
  http://savannah.nongnu.org/





reply via email to

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