[Top][All Lists]

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

Re: [lwip-users] Custom memory management

From: address@hidden
Subject: Re: [lwip-users] Custom memory management
Date: Thu, 06 Oct 2011 17:42:56 +0200
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1

First, please *don't* CC me, I'm getting mails twice that way!

Mason wrote:
I've defined a new struct packet_info_t which stores a pbuf
(for lwip) and an OS descriptor.

typedef struct { struct pbuf_custom pbuf; ethernet_async_t desc; } packet_info_t;
Where's the actual memory (i.e. p->payload) in this structure?

And when lwip wants to free the custom pbuf, it calls my
custom function. Seems to work OK. What is the problem
with this strategy?
First, said that it doesn't work (yet) with PBUF_REF but you're using PBUF_RAM.

Second, the code assumes that for a PBUF_RAM, the payload directly follows the struct pbuf. This is important when pbuf_header should make room for more headers in the pbuf. However, that's not used often on RX pbufs (I think it's only really used when answering ping packets), so this might work OK for you (even if it's not strictly correct for the above reasons).
As to the TX side: normally, TX pbufs are allocated as PBUF_RAM, the 
memory for that is taken from the heap by calling mem_malloc(). Now the 
simple solution would be to just replace mem.c by your own code 
allocating and freeing from your TX pool: with the correct settings, 
mem_malloc() isn't used for anything else but PBUF_RAM pbufs. The only 
problem might be that you don't know in advance how big the memory 
blocks are (and thus how big your TX buffer entries should be), but by 
using TCP_OVERSIZE, you can just use the maximum ethernet frame size (if 
you don't mind wasting some RAM for smaller packets).
RX and TX buffers are large enough to store a full-sized
Ethernet frame, i.e. MAX_FRAME_SIZE is defined to 1536
(for alignment reasons).

However, I was trying to make the port as clean as possible
by making as few modifications inside lwip as possible.
After looking at the code, the cleaner solution is to define MEM_LIBC_MALLOC to 1 and then define mem_malloc (etc.) to your own functions (see mem.h in the upper half).


reply via email to

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