|
From: | address@hidden |
Subject: | Re: [lwip-users] Packet queuing to an ARP table entry |
Date: | Tue, 14 Nov 2017 22:31:08 +0100 |
User-agent: | Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 |
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
[Prev in Thread] | Current Thread | [Next in Thread] |