On Sun, Jun 11, 2023 at 09:24:14AM +0100, Simon Glass wrote:
Hi,
On Wed, 7 Jun 2023 at 10:47, Ilias Apalodimas ilias.apalodimas@linaro.org wrote:
Hi Maxim,
On Tue, 6 Jun 2023 at 17:33, Maxim Uvarov maxim.uvarov@linaro.org wrote:
Greetings,
I implemented the tftp client (that was quick due to lwip has example app for tftp), and did some more measurements. I uploaded patches here if somebody want to do his own measurements: https://github.com/muvarov/uboot-lwip
measure 1: 976K - total (total means lwip with all 3 commands ping, tftp, wget) 971K - total - tftp (total, but disable/minus tftp) 965K - total - tftp - wget (disable tftp and wget) 963K - total - tftp - wget - ping (disable tftp, wget, ping) 931K - no lwip
result 1: lwip tftp (+ udp protocol) protocol 976-971k = 5kb result 2: lwip ping command 965- 963 = 2kb result 3: lwip wget command 971- 965 = 6kb result 4: lwip core stack with apps 976 - 931 = 45kb
So tftp = 5kb, wget = 6kb ping =2kb and lwip = 32kb
measure 2: 890K - no CONFIG_NET_CMD 930K - + lwip tftp only 937K - + full lwip (ping wget tftp)
result 1: 937-890=47kb ( lwip + all 3 commands) result 2: 937-930=7kb (ping and lwip command)
I am not sure I understand this measurement. How is this different from measurement 1 where the entire binary was 976K?
measure 3: 904K - no lwip, CMD_NET_TFTP=y 900K - no lwip, CMD_NET_TFTP=n result 1: original u-boot tftp command 904-900=4kb 890K - no lwip, CMD_NET=n result 2: 900-890=10k original u-boot net/IP stack.
My findings for all that measurements and lwip configuration:
- The original u-boot net stack (packet process and up layers) is 10k vs lwip 40k (the very minimal settings were 30k).
- Network applications size is about the same 4kb for tftp original command 5kb for lwip.
- It's quite easy to reuse LWIP examples to implement the same functionality for the U-boot.
- I still think that there are other criterias which might have more priority than size (bug free code, code reuse, development speed, compatible API to posix and etc).
Yes, there are other criteria and certainly having a complete network stack might be worth it in many cases, but we need to keep in mind 30kb might be a lot for some systems.
I personally think this is decent and we can optimize lwip more in the future. Tom, Simon, how about adding lwip as 'experimental' and making it depend on !CMD_NET or something similar?
That seems OK to me, but we don't really want two network stacks, so we'd need to set an expectation that we would move to lwip.
Yes, we'll need to move on to evaluating that once we can show and use lwip as a replacement for most cases.
I wonder why it is so large? I saw mention of it supporting multiple buffers and perhaps having a fuller implementation of the protocols. But it makes U-Boot's stack seem super-slim in comparison. I wonder if lwip could support just a single buffer and reduced functionality in other areas?
Well, right. Seeing what space related tuneables we can introduce and/or further tune down will be of interest. But that will be easier to do once it's easier to try out lwip in U-Boot itself.