lwip-devel
[Top][All Lists]
Advanced

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

RE: [lwip-devel] [bug #3031] Implement a new fully pool-based pbufimplem


From: Pettinato, Jim
Subject: RE: [lwip-devel] [bug #3031] Implement a new fully pool-based pbufimplementation.
Date: Tue, 6 Mar 2007 09:13:10 -0500

FYI... I went a long way towards achieving this with some precompiler
logic in tcp_out.c (which was really the only consumer of PBUF_RAM
memory in my situation)... that and judiciously selecting a pool size
big enough to hold any outgoing packet (including headers, list
pointers, and all).

Most of my other heap allocations were relatively safe (one per
interface, etc) so I wasn't so worried about them.

End result: everything pbuf is out of the pool. 

  ..\archives\tcp_out.c_v Rev 1.1 (27 Dec 2003 21:38:52)
           tcp_out.c (13 Apr 2004 14:19:32)
==============
+        94  |#define TCP_MAX_BUFLEN
(TCP_MSS+PBUF_TRANSPORT_HLEN+PBUF_IP_HLEN+PBUF_LINK_HLEN)
==============
   177  179  |    else if (copy) {
+       180  |#if (PBUF_POOL_BUFSIZE > TCP_MAX_BUFLEN)  // we know we
can get away with using the pool
+       181  |      if ((seg->p = pbuf_alloc(PBUF_TRANSPORT, seglen,
PBUF_POOL)) == NULL) {
+       182  |#else
   178  183  |      if ((seg->p = pbuf_alloc(PBUF_TRANSPORT, seglen,
PBUF_RAM)) == NULL) {
+       184  |#endif
   179  185  |        LWIP_DEBUGF(TCP_OUTPUT_DEBUG | 2, ("tcp_enqueue :
could not allocate memory for pbuf copy size %u\n", seglen));
   180  186  |        goto memerr;
==============

Note: I haven't kept up with lwip releases and this was based on 0.7.0
code; don't think anything changed in that area though.

- Jim


-----Original Message-----
From: address@hidden
[mailto:address@hidden On Behalf
Of Simon Goldschmidt
Sent: Tuesday, March 06, 2007 3:27 AM
To: Simon Goldschmidt; address@hidden; address@hidden
Subject: [lwip-devel] [bug #3031] Implement a new fully pool-based
pbufimplementation.



Follow-up Comment #1, bug #3031 (project lwip):

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)

Implementing fully pooled pbufs would be one step into that direction.
BUT: I think this would only make sense if mem_malloc() could be
eliminated for the rest of the core code. Since this is mainly dhcp and
snmp, I hope introducing new memp pools for those would be enough.

This could also solve the issue where no pbufs were free to acknowledge
tcp segments (which again would free some tcp enqueued pbufs). This was
an error report somewhere, though I don't remeber it.

I'm not planning to take on this right now, just wanted to know your
opinions.

    _______________________________________________________

Reply to this item at:

  <http://savannah.nongnu.org/bugs/?3031>

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



_______________________________________________
lwip-devel mailing list
address@hidden
http://lists.nongnu.org/mailman/listinfo/lwip-devel




reply via email to

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