What perhaps may change is the response of any networking stack above it based on it not fragmenting packets etc. I don't believe the NetServices code to be that efficient anyway (I don't know that codebase), and I expect the different behaviour is it allocating different buffers based on the improved/different network performance.
Definitely worth some more investigation.
I have been playing around with the lwIP network stack and trying to learn more about how to use it and one of the recent things I have been looking at is memory usage, to see how it can be tweaked for particular applications. That put me on the track of doing some more investigating into what actually caused the decrease in the free heap size that Daniel saw with the larger Ethernet MTU beta.
Let's start with Daniel's test program here. This version includes the beta version of the mbed library. If I dump the static RAM allocations for this sample I see:
Main RAM = 11956
RAM0 = 0
RAM1 = 13876
Now take the same sample and roll it back to the current mbed library:
Main RAM = 4916
RAM0 = 0
RAM1 = 15556
You will notice that the amount of statically allocated memory in main RAM was drastically increased when you use the beta version of the mbed library. My theory is that the NetServices library wants to place a bunch of statics in the Ethernet RAM bank but the Ethernet layer is using up so much space, it doesn't fit so it ends up rolling over into the main RAM bank instead.
Some additional proof for this theory is when we look at a basic Ethernet sample taken from the API docs themselves to just print the source and destination MAC addresses.
Start with the current mbed library and we see the following static allocations:
Main RAM = 620
RAM0 = 0
RAM1 = 5476
Switch to the beta mbed library and we see the following static allocations:
Main RAM = 608
RAM0 = 0
RAM1 = 10852
If we subtract the 13,876 bytes which did make it into the the Ethernet RAM bank in Daniel's sample using the beta library and the 10,852 bytes used by the Ethernet portion of the beta library itself, we are left with 3,024 bytes. This would suggest that the 3000 bytes of heap (MEM_SIZE) configured for lwIP by lwipopts.h made it into this bank, along with 24 bytes of other statics (probably a few global pointers, etc.) and then the lwIP memory pool (it's largest allocation) ended up getting pushed down into the main RAM bank.
Were you expecting to use up 10.5k of memory out of this RAM bank for the Ethernet code alone or is there a bug which is causing the size to get bloated?
We've posted a beta mbed library v29 at http://mbed.org/projects/libraries-testing/svn/beta
The main highlights are:
If you want to test the library, just delete the "mbed" library amd choose "Import Library..." with the URL as http://mbed.org/projects/libraries-testing/svn/beta
I've also published a version of the CMSIS DSP Library that will work with this update that can be found here:
CMSIS DSP Library from CMSIS 2.0. See http://www.onarm.com/cmsis/ for full details
Last commit 10 Mar 2011 by Simon Ford
The auto-documentation is pretty comprehensive, but hard to find with our current indexes, so here are the functions available:
Note it is currently an uncompiled library so is not the fastest to build, but gives an early opportunity to explore running DSP functions on mbed. For more information on this library, you can visit http://www.onarm.com/cmsis/
Please report any problems you find with this library, and we'll aim to finalise and mainline it over the next couple fo weeks.