Re: [lwip-users] Packet queuing to an ARP table entry

[Amena El Homsi]

Hi Simon,

Thanks for you Reply!

We are working on designing Low power Wireless SoC. We have few restrictions concerning the memory usage.

Our memory system is divided in:

1. Instructions memory
2. Data memory
3. Frame memory

Incoming and Outgoing frames should be saved in frame memory. However LwIP uses the data memory to create the pools and process incoming frames using PBUF_POOL pools created by  LWIP_PBUF_MEMPOOL() and outgoing frames using PBUF_RAM pools created by LWIP_MALLOC_MEMPOOL(). In this case I have to copy the incoming frames from frame memory to data memory (by allocating pbuf of type PBUF_POOL)  and  I have to copy the outgoing frames from data memory (pbuf of type PBUF_RAM) to frame memory.

My goal is to avoid:

1. Wasting the data memory by LwIP memory Pools (especially the pools of type PBUF_POOL used for incoming frames and the pools of type PBUF_RAM used for Outgoing frames)
2. Copying from data memory to frame memory and vice versa which consumes power and time

That's why I am using the PBUF_ROM with payload pointer pointing to the actual data in the frame memory. What I know is PBUF_ROM doesn't mean the actual ROM (stable for very long) but it means that the data is immutable and it is located in memory which is not managed by the pbuf system. Am I wrong? Do you have another Solution?

Concerning the issue listed in the previous email, you suggested to "create a new ROM pbuf referencing the same data, which would prevent copying", so I have to add some instructions inside the LwIP code, right?

Regards,

Amena

On Tue, Nov 14, 2017 at 11:31 PM, address@hidden <address@hidden> wrote:

Amena El Homsi wrote:

I am trying to send ping request using Lwip.
The ICMP header and ping data is in my system frame memory referenced by a PBUF_ROM 'p' (p->payload points to the ICMP hdr in the frame memory.

Is this correct? How long is the contents of this buffer stable? PBUF_ROM means ROM - i.e. stable for very long, not just until you think normal transmission is done. This is *not* very common!

The PBUF_ROM is chained by a PBUF_RAM 'q' in which the ETHERNET and IP headers are saved
[..]
When I tried to send the first ping, LwIP sends an ARP request and queue the packet. The problem is that LwIP creates a new pbuf RAM 'r' and copies 'q' of type PBUF RAM and 'p' of type PBUF_ROM to the new PBUF RAM!

I guess it's like that since your case is just very uncommon. Noone has ever bothered to improve for this. Normally, even if you have PBUF_ROM pbufs at some point, they are not the first frames sent to some devices. Plus it's normally not worth to improve for not copying here.

Indeed I don't want to copy PBUF_ROM payload to the new PBUF_RAM, is there a way to avoid such copy? why LwIP doesn't copy 'q' to 'r' while preserving the chain between the PBUF_RAM and PBUF_ROM?

Now this might work for the special case where the last pbuf(s) in a chain are ROM (remember we need to copy all non-ROM pbufs). We could of course create a new ROM pbuf referencing the same data, which would prevent copying.

May I ask why it's worth making this change? I.e. does it really hurt performance or memory constraints in your case?


Simon

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

--

Amena El-Homsi

Computer & Communication Engineer

Dipl. Eng,  M.S.