ETH_LWIP slimdown

[#1]

Hi,

I'm trying to reduce the RAM consumption of ETH_LWIP.
Could anyone suggest some reasonable reductions, from the settings below ?
I inherited the settings from the Infineon DAVE example project for Modbus TCP.
Modbus TCP, and the occasional ping, is what we are using ETH_LWIP for.
So I have always been rather hesitant to change any of the settings below,
for fear I might break the Modbus TCP operation.





I particularly wonder, which setting or settings, might reduce the giant 24835 byte item,
at the top of the list below. This list is from the Ozone debugger. I filtered for memp items,
which as I understand, are to do with ETH_LWIP. Then sorted with largest first.



The odd thing about the 24835 byte item, is that if you expand it, it is just a 512 byte array.
So I wonder, some kind of allocation bug, with ETH_LWIP ?
Or the Ozone debugger getting confused, or having a 512 element displayable limit, perhaps ?
Other memp items, if I expand them, have content that matches their size.

Here's a few more items, this time filtering for ETH_LWIP:



In the second screengrab of this post, the Simultaneously active TCP connections setting,
I imagine could be reduced from 5, maybe even to 1, as the FreeModbus library that
Infineon use for their Modbus TCP example project, allows only one Modbus TCP client,
to be connected at a time.

Although perhaps, reducing that setting to 1, wouldn't save much RAM.

Really, I don't know which settings, have which effect on RAM, or which I could safely reduce.

In case this info helps, Modbus TCP packets are 94 to 341 bytes in, 93 to 341 bytes out.
With the pattern being in, out, in, out, etc. Thus only ever one packet active. If the in packet
is large, the out is small, being a write. And vice-versa, being a read. Though typically both
are small. Those figures from Layer 1 Ethernet packet preamble start, to FCS end.

To add to the above, the occasional ping. And very occasionally, perhaps, a ping attack.

So I would guess, the settings shown in the screen grabs, are far higher than needed.
Particularly whichever setting or settings result in the 24835 byte item.

Best regards,

David King

[jferreira]

Hi David,

You can reduce the number of receive and transmit buffers. The minimum should be 2.
If you are not going to need UDP, you can disable UDP.

Then if you look into the map file the variables which are requiring more memory are:

 
 .bss.memp_memory_PBUF_POOL_base
                0x1ffe9584     0x6104 ./Dave/Generated/ETH_LWIP/lwip/core/memp.o
                0x1ffe9584                memp_memory_PBUF_POOL_base

The memp_memory_PBUF_POOL_base is related to the Packet buffer pool size (PBUF_POOL_SIZE). This one is used in the network interface for receiving packets. You can reduce this one to 4. In case of high load you will start loosing packets, i.e. not able to allocate a pbuf.
http://www.nongnu.org/lwip/2_0_x/group__pbuf.html

We are planning to add zero copy RX in a next release. This will reduce the memory requirements and will increase RX throughput, i.e. network driver will copy received data directly to the pbuf.

Regards,
Jesus


Regards,
Jesus

[#3]

Hi Jesus,

Finally I got to this on my todo list. I've done all as you say, and it has made a commensurate reduction in the memp and ETH_LWIP RAM requirements. Thank you. UDP I already had disabled.

But now I have a problem with Flash usage: My app is too Flash hungry, to allow me to go back from optimise level -O2, to -O3, which I used to be able to use.

Anything else I could try lowering, from my original email, that would lower the Flash requirement ? Number of allowed TCP connections ? Or wouldn't that help much ?

About RAM, I've pruned back in all other areas of my app, although the CANopen Node stack remains the main user, due to perfect storm of standards compliance and stack contiguous 1 onward PDO requirement. But that's another story.

Best regards,

David