Re: [lwip-users] Custom memory management

[Mason]

Simon wrote:

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

I'm not sure I understand the question. The RX buffers
are managed by the driver. The desc structure stores a
pointer to one such buffer.

 * @param payload_mem pointer to the buffer that is used for payload and 
headers,
 *        must be at least big enough to hold 'length' plus the header size,
 *        may be NULL if set later

The payload_mem param is desc->buffer

struct pbuf *pbuf =
  pbuf_alloced_custom(PBUF_RAW, desc->length, PBUF_RAM, &info->pbuf, 
desc->buffer, MAX_FRAME_SIZE);

pbuf_alloced_custom sets p->pbuf.payload to
LWIP_MEM_ALIGN((void *)((u8_t *)payload_mem + offset));
offset being 0 because the layer flag is PBUF_RAW.

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

Is there a place where the different pbuf_type types are explained?
(And the assumptions tied to each type)
The comment for PBUF_REF says "pbuf comes from the pbuf pool".
I avoided this type because, AFAIU, the buffer didn't come from
that pool.

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

Ugh, I don't think I can rely on "might work OK for you"  ;-(

Well, I guess it's back to the drawing board for the RX
solution :-(

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

Thanks for the pointer, I will definitely look at this
approach.

-- 
Regards.