Re: [lwip-devel] [RFC PATCH 0/5] LWIP stack integration
On Sun, Jun 11, 2023 at 09:24:14AM +0100, Simon Glass wrote: > Hi, > > On Wed, 7 Jun 2023 at 10:47, Ilias Apalodimas > wrote: > > > > Hi Maxim, > > > > On Tue, 6 Jun 2023 at 17:33, Maxim Uvarov 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: > > > 1. The original u-boot net stack (packet process and up layers) is 10k vs > > > lwip 40k (the very minimal settings were 30k). > > > 2. Network applications size is about the same 4kb for tftp original > > > command 5kb for lwip. > > > 3. It's quite easy to reuse LWIP examples to implement the same > > > functionality for the U-boot. > > > 4. 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. -- Tom signature.asc Description: PGP signature
Re: [lwip-devel] [RFC PATCH 0/5] LWIP stack integration
Hi, On Wed, 7 Jun 2023 at 10:47, Ilias Apalodimas wrote: > > Hi Maxim, > > On Tue, 6 Jun 2023 at 17:33, Maxim Uvarov 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: > > 1. The original u-boot net stack (packet process and up layers) is 10k vs > > lwip 40k (the very minimal settings were 30k). > > 2. Network applications size is about the same 4kb for tftp original > > command 5kb for lwip. > > 3. It's quite easy to reuse LWIP examples to implement the same > > functionality for the U-boot. > > 4. 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. 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? Regards, Simon > > Thanks > /Ilias > > > > BR, > > Maxim. > > > > On Thu, 25 May 2023 at 02:18, Simon Goldschmidt wrote: > >> > >> Hi Maxim, Tom, > >> > >> On 24.05.2023 16:05, Maxim Uvarov wrote: > >> > On Tue, 23 May 2023 at 03:23, Tom Rini wrote: > >> > > >> >> On Mon, May 22, 2023 at 12:40:49PM -0400, Maxim Uvarov wrote: > >> >>> On Mon, 22 May 2023 at 10:20, Tom Rini wrote: > >> >>> > >> On Mon, May 22, 2023 at 04:33:57PM +0300, Ilias Apalodimas wrote: > >> > Hi Maxim > >> > > >> > On Mon, 22 May 2023 at 12:01, Maxim Uvarov > >> wrote: > >> >> > >> >> My measurements for binary after LTO looks like: > >> >> > >> >> U-boot WGET | LWIP WGET + ping | LWIP WGET| diff bytes| diff % > >> >> 870728| 915000| 912560 | > >> 41832| 4.8 > >> > > >> > > >> > I think you'll need to analyze that a bit more. First of all I don't > >> > think the '+ping' tab is useful. What is is trying to achieve? > >> > >> >>> > >> >>> To show the difference of extra bytes if we add a ping app on top. > >> >>> > >> >>> > >> > - How was LWIP compiled? > >> > >> >>> > >> >>> It has a really huge configuration. I tried to turn off everything off > >> >>> everything what can impact on size but still make http app work: > >> >>> #define LWIP_HAVE_LOOPIF0 > >> >>> #define LWIP_NETCONN0 > >> >>> #define LWIP_SOCKET 0 > >> >>> #define SO_REUSE0 > >> >>> #define LWIP_STATS 0 > >> >>> #define PPP_SUPPORT 0 > >> >>> > >> >>> Disabling loopback: > >> >>> #define LWIP_NETIF_LOOPBACK 0 > >> >>> can lower to 912288 bytes. > >> >>> > >> >>> And it's the same compilation option (optimization for size) as the > >> >>> main > >> >>> u-boot. I will do more experiments, but I think the goal is not to turn > >> >> off > >> >>> everything. > >> >>> > >> >>> > >> > - Was ipv6 supported? > >> > >> >>> > >> >>> No. I.e. when
Re: [lwip-devel] [RFC PATCH 0/5] LWIP stack integration
On Thu, Jun 8, 2023 at 6:56 PM Ilias Apalodimas wrote: > > Thanks Maxim, > > On Thu, 8 Jun 2023 at 13:14, Maxim Uvarov wrote: > > > > Ilias asked to make more clear results to compare the original stack and > > LWIP stack. So the difference between the current U-boot stack and the LWIP > > stack with 3 network commands is: > > a) 18Kb - ls -lh size > > b) 15Kb - bloat-o-meter script total line report. > > > > BOM=linux/scripts/bloat-o-meter (script) > > > > 1. 893K - U-boot CMD_NET=n > > 2. 928K - U-boot CMD_NET=y TFTP=y PING=y WGET=y > > BOM 1-2: Total: Before=692286, After=722283, chg +4.33% > > 3. 940K - U-boot CMD_NET=n, LWIP_TFTP=y LWIP_PING=y LWIP_PING=y > > BOM 1-3: Total: Before=692286, After=738425, chg +6.66% > > That's much more readable! I discussed this with Tom over IRC and the > size difference is certainly a reasonable trade-off for the extra > functionality. Yes, this looks great! I'm also sure with a closer look there could be further optimisations here in time as well. I feel having a widely used IP stack that's also widely audited is a big win here, it will also provide things like HTTP, DNS and IPv6 without having to reinvent the wheel. > Can you tidy up the series and include DHCP and PXE done through LWIP? I'll look forward to this. > Thanks > /Ilias > > > > BOM 2-3: > > > > add/remove: 287/203 grow/shrink: 3/11 up/down: 43459/-27317 (16142) > > Function old new delta > > tcp_input -3588 +3588 > > tcp_receive-2884 +2884 > > ip4_reass -1760 +1760 > > tcp_output -1400 +1400 > > tcp_write -1300 +1300 > > tcp_slowtmr-1172 +1172 > > httpc_tcp_recv -1044 +1044 > > tftp_recv - 888+888 > > ip4_input - 700+700 > > ip4_frag - 632+632 > > icmp_input - 604+604 > > udp_input - 596+596 > > etharp_input - 512+512 > > tcp_split_unsent_seg - 500+500 > > ip4addr_aton - 492+492 > > tcp_alloc - 484+484 > > ip4_output_if_src - 476+476 > > tcp_close_shutdown - 448+448 > > etharp_query - 436+436 > > httpc_init_connection_common.constprop - 416+416 > > udp_sendto_if_src - 408+408 > > etharp_output - 404+404 > > arp_table - 400+400 > > tcp_connect- 396+396 > > pbuf_alloc - 376+376 > > etharp_find_entry - 372+372 > > tcp_abandon- 368+368 > > tcp_zero_window_probe - 356+356 > > raw_sendto_if_src - 328+328 > > pbuf_copy_partial_pbuf - 328+328 > > ip_reass_free_complete_datagram- 328+328 > > tcp_create_segment - 300+300 > > raw_input - 292+292 > > uboot_lwip_init- 284+284 > > ethernet_input - 284+284 > > etharp_raw - 284+284 > > tcp_output_alloc_header_common.constprop - 280+280 > > cmds - 280+280 > > udp_bind - 276+276 > > tcp_oos_insert_segment - 276+276 > > ip_reass_remove_oldest_datagram- 272+272 > > icmp_send_response - 268+268 > > netif_add - 260+260 > > ping_send - 244+244 > > tcp_rexmit - 232+232 > > tcp_parseopt - 220+220 > > tcp_free_acked_segments.constprop - 220+220 > > send_request - 220+220 > > inet_chksum_pseudo - 216+216 > > ip4addr_ntoa_r - 212+212 > > do_lwip_ping - 212+212 > >
Re: [lwip-devel] [RFC PATCH 0/5] LWIP stack integration
Thanks Maxim, On Thu, 8 Jun 2023 at 13:14, Maxim Uvarov wrote: > > Ilias asked to make more clear results to compare the original stack and LWIP > stack. So the difference between the current U-boot stack and the LWIP stack > with 3 network commands is: > a) 18Kb - ls -lh size > b) 15Kb - bloat-o-meter script total line report. > > BOM=linux/scripts/bloat-o-meter (script) > > 1. 893K - U-boot CMD_NET=n > 2. 928K - U-boot CMD_NET=y TFTP=y PING=y WGET=y > BOM 1-2: Total: Before=692286, After=722283, chg +4.33% > 3. 940K - U-boot CMD_NET=n, LWIP_TFTP=y LWIP_PING=y LWIP_PING=y > BOM 1-3: Total: Before=692286, After=738425, chg +6.66% That's much more readable! I discussed this with Tom over IRC and the size difference is certainly a reasonable trade-off for the extra functionality. Can you tidy up the series and include DHCP and PXE done through LWIP? Thanks /Ilias > > BOM 2-3: > > add/remove: 287/203 grow/shrink: 3/11 up/down: 43459/-27317 (16142) > Function old new delta > tcp_input -3588 +3588 > tcp_receive-2884 +2884 > ip4_reass -1760 +1760 > tcp_output -1400 +1400 > tcp_write -1300 +1300 > tcp_slowtmr-1172 +1172 > httpc_tcp_recv -1044 +1044 > tftp_recv - 888+888 > ip4_input - 700+700 > ip4_frag - 632+632 > icmp_input - 604+604 > udp_input - 596+596 > etharp_input - 512+512 > tcp_split_unsent_seg - 500+500 > ip4addr_aton - 492+492 > tcp_alloc - 484+484 > ip4_output_if_src - 476+476 > tcp_close_shutdown - 448+448 > etharp_query - 436+436 > httpc_init_connection_common.constprop - 416+416 > udp_sendto_if_src - 408+408 > etharp_output - 404+404 > arp_table - 400+400 > tcp_connect- 396+396 > pbuf_alloc - 376+376 > etharp_find_entry - 372+372 > tcp_abandon- 368+368 > tcp_zero_window_probe - 356+356 > raw_sendto_if_src - 328+328 > pbuf_copy_partial_pbuf - 328+328 > ip_reass_free_complete_datagram- 328+328 > tcp_create_segment - 300+300 > raw_input - 292+292 > uboot_lwip_init- 284+284 > ethernet_input - 284+284 > etharp_raw - 284+284 > tcp_output_alloc_header_common.constprop - 280+280 > cmds - 280+280 > udp_bind - 276+276 > tcp_oos_insert_segment - 276+276 > ip_reass_remove_oldest_datagram- 272+272 > icmp_send_response - 268+268 > netif_add - 260+260 > ping_send - 244+244 > tcp_rexmit - 232+232 > tcp_parseopt - 220+220 > tcp_free_acked_segments.constprop - 220+220 > send_request - 220+220 > inet_chksum_pseudo - 216+216 > ip4addr_ntoa_r - 212+212 > do_lwip_ping - 212+212 > tcp_enqueue_flags - 208+208 > etharp_output_to_arp_index - 208+208 > netif_set_addr - 204+204 > tcp_fasttmr- 200+200 > tcp_rexmit_rto_prepare - 196+196 > tcp_process_refused_data - 196+196 > send_data - 196+196 > lwip_wget - 192+192 >
Re: [lwip-devel] [RFC PATCH 0/5] LWIP stack integration
Ilias asked to make more clear results to compare the original stack and LWIP stack. So the difference between the current U-boot stack and the LWIP stack with 3 network commands is: a) 18Kb - ls -lh size b) 15Kb - bloat-o-meter script total line report. BOM=linux/scripts/bloat-o-meter (script) 1. 893K - U-boot CMD_NET=n 2. 928K - U-boot CMD_NET=y TFTP=y PING=y WGET=y BOM 1-2: Total: Before=692286, After=722283, chg +4.33% 3. 940K - U-boot CMD_NET=n, LWIP_TFTP=y LWIP_PING=y LWIP_PING=y BOM 1-3: Total: Before=692286, After=738425, chg +6.66% BOM 2-3: add/remove: 287/203 grow/shrink: 3/11 up/down: 43459/-27317 (16142) Function old new delta tcp_input -3588 +3588 tcp_receive-2884 +2884 ip4_reass -1760 +1760 tcp_output -1400 +1400 tcp_write -1300 +1300 tcp_slowtmr-1172 +1172 httpc_tcp_recv -1044 +1044 tftp_recv - 888+888 ip4_input - 700+700 ip4_frag - 632+632 icmp_input - 604+604 udp_input - 596+596 etharp_input - 512+512 tcp_split_unsent_seg - 500+500 ip4addr_aton - 492+492 tcp_alloc - 484+484 ip4_output_if_src - 476+476 tcp_close_shutdown - 448+448 etharp_query - 436+436 httpc_init_connection_common.constprop - 416+416 udp_sendto_if_src - 408+408 etharp_output - 404+404 arp_table - 400+400 tcp_connect- 396+396 pbuf_alloc - 376+376 etharp_find_entry - 372+372 tcp_abandon- 368+368 tcp_zero_window_probe - 356+356 raw_sendto_if_src - 328+328 pbuf_copy_partial_pbuf - 328+328 ip_reass_free_complete_datagram- 328+328 tcp_create_segment - 300+300 raw_input - 292+292 uboot_lwip_init- 284+284 ethernet_input - 284+284 etharp_raw - 284+284 tcp_output_alloc_header_common.constprop - 280+280 cmds - 280+280 udp_bind - 276+276 tcp_oos_insert_segment - 276+276 ip_reass_remove_oldest_datagram- 272+272 icmp_send_response - 268+268 netif_add - 260+260 ping_send - 244+244 tcp_rexmit - 232+232 tcp_parseopt - 220+220 tcp_free_acked_segments.constprop - 220+220 send_request - 220+220 inet_chksum_pseudo - 216+216 ip4addr_ntoa_r - 212+212 do_lwip_ping - 212+212 tcp_enqueue_flags - 208+208 etharp_output_to_arp_index - 208+208 netif_set_addr - 204+204 tcp_fasttmr- 200+200 tcp_rexmit_rto_prepare - 196+196 tcp_process_refused_data - 196+196 send_data - 196+196 lwip_wget - 192+192 ethernet_output- 192+192 ping_recv - 188+188 pbuf_memcmp- 184+184 pbuf_copy_partial - 184+184 httpc_free_state - 180+180 tcp_send_fin - 172+172 httpc_recv - 168+168
Re: [lwip-devel] [RFC PATCH 0/5] LWIP stack integration
On Wed, May 24, 2023 at 10:18:13PM +0200, Simon Goldschmidt wrote: > Hi Maxim, Tom, > > On 24.05.2023 16:05, Maxim Uvarov wrote: > > On Tue, 23 May 2023 at 03:23, Tom Rini wrote: > > > > > On Mon, May 22, 2023 at 12:40:49PM -0400, Maxim Uvarov wrote: > > > > On Mon, 22 May 2023 at 10:20, Tom Rini wrote: > > > > > > > > > On Mon, May 22, 2023 at 04:33:57PM +0300, Ilias Apalodimas wrote: > > > > > > Hi Maxim > > > > > > > > > > > > On Mon, 22 May 2023 at 12:01, Maxim Uvarov > > > > > wrote: > > > > > > > > > > > > > > My measurements for binary after LTO looks like: > > > > > > > > > > > > > > U-boot WGET | LWIP WGET + ping | LWIP WGET| diff bytes| diff % > > > > > > > 870728| 915000| 912560 | > > > > > 41832| 4.8 > > > > > > > > > > > > > > > > > > I think you'll need to analyze that a bit more. First of all I > > > > > > don't > > > > > > think the '+ping' tab is useful. What is is trying to achieve? > > > > > > > > > > > > > To show the difference of extra bytes if we add a ping app on top. > > > > > > > > > > > > > > - How was LWIP compiled? > > > > > > > > > > > > > It has a really huge configuration. I tried to turn off everything off > > > > everything what can impact on size but still make http app work: > > > > #define LWIP_HAVE_LOOPIF0 > > > > #define LWIP_NETCONN0 > > > > #define LWIP_SOCKET 0 > > > > #define SO_REUSE0 > > > > #define LWIP_STATS 0 > > > > #define PPP_SUPPORT 0 > > > > > > > > Disabling loopback: > > > > #define LWIP_NETIF_LOOPBACK 0 > > > > can lower to 912288 bytes. > > > > > > > > And it's the same compilation option (optimization for size) as the main > > > > u-boot. I will do more experiments, but I think the goal is not to turn > > > off > > > > everything. > > > > > > > > > > > > > > - Was ipv6 supported? > > > > > > > > > > > > > No. I.e. when I sent results it was enabled on the compilation stage > > > > but > > > > not used. I just checked that size remains the same if IPv6 is not even > > > > compiled. > > > > > > > > > > > > > > - Can we strip it down even further? > > > > > > > > > > > > > > > > > > > There is always room for optimization. I think I tried to turn off > > > > everything that is configurable with defines. I can play with disable IP > > > > reassembly and things like that or figure out which functions have more > > > > size and if it's possible to exclude them. > > > > > > > > > > > > > > In general please give as much information as you can with what we > > > > > > gain in functionality from LWIP with those extra bytes of code. > > > > > > > > > > > > > > The main idea is to reuse a maintainable IP stack outside of U-boot. > > > LWIP > > > > can give a nice separation between IP stack code and network application > > > > code. I.e. application should not take care about any TCP details > > > > (SYN, > > > > ACK, retransmission, reassembly etc) and should open connection and use > > > > functions similar to recv() and send() to transfer data. Data means > > > > application data, no network packets. And LWIP allows > > > > us to do that. > > > > Because LWIP has an API similar to sockets, it has to be very easy to > > > port > > > > a linux application to LWIP. Then you can test it with a tap device. > > > > Then > > > > copy sources to U-boot, add a small integration layer (cmd command to > > > > call), compile and use. > > > > > > > > So my suggestion was: > > > > - do not maintain new network stack code in the current U-boot. Use > > > > lwip > > > > sources as an external project. All bugs related to network stack go to > > > > lwip project first, then sync with U-boot. > > > > - maintain network apps code* or > > > >-- inside U-boot. Write our own code for application and maintain it > > > > inside U-boot. > > > >-- inside LWIP. Add examples to LWIP which are suitable for both > > > U-boot > > > > and LWIP. > > > > > > > > * Let's define a U-boot network application as a cmd command. It might > > > > be > > > > ping, wget (http or https download), telnet, arp dns etc.. > > > > > > > > Let's consider the real use case, like HTTPS download client. We need to > > > > enable TLS connection, validate certificates, then do http download. > > > > Looking at the current code of wget command it's quite difficult to > > > > implement this due to the application having some protol level things. > > > > On > > > > the other side we can find embedTLS examples to do https download on > > > > sockets. If LWIP socket API is ported then the only thing you need to do > > > is > > > > change socket() -> lwip_socket(), recv()->lwip_recv(), > > > send()->lwip_send() > > > > and etc, even function names are similar. If LWIP socket API is not > > > > supported, then use callback API for recv() and send(), which are also > > > > easy. > > > > > > >
Re: [lwip-devel] [RFC PATCH 0/5] LWIP stack integration
On Wed, 7 Jun 2023 at 15:47, Ilias Apalodimas wrote: > Hi Maxim, > > On Tue, 6 Jun 2023 at 17:33, Maxim Uvarov 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 > > tftp also compiles in the UDP stack. So if there will be one more UDP application, then this size will be lower. > > > > 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? > > This is when NET_CMD is off and LWIP is off also. First measurement had NET_CMD=y. (moved numbers to separate changes due to u-boot can not just enable only tfpt command due to a compilation error and had to fix it.). > > > 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: > > 1. The original u-boot net stack (packet process and up layers) is 10k > vs lwip 40k (the very minimal settings were 30k). > > 2. Network applications size is about the same 4kb for tftp original > command 5kb for lwip. > > 3. It's quite easy to reuse LWIP examples to implement the same > functionality for the U-boot. > > 4. 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? > > Thanks > /Ilias > > > > BR, > > Maxim. > > > > On Thu, 25 May 2023 at 02:18, Simon Goldschmidt > wrote: > >> > >> Hi Maxim, Tom, > >> > >> On 24.05.2023 16:05, Maxim Uvarov wrote: > >> > On Tue, 23 May 2023 at 03:23, Tom Rini wrote: > >> > > >> >> On Mon, May 22, 2023 at 12:40:49PM -0400, Maxim Uvarov wrote: > >> >>> On Mon, 22 May 2023 at 10:20, Tom Rini wrote: > >> >>> > >> On Mon, May 22, 2023 at 04:33:57PM +0300, Ilias Apalodimas wrote: > >> > Hi Maxim > >> > > >> > On Mon, 22 May 2023 at 12:01, Maxim Uvarov < > maxim.uva...@linaro.org> > >> wrote: > >> >> > >> >> My measurements for binary after LTO looks like: > >> >> > >> >> U-boot WGET | LWIP WGET + ping | LWIP WGET| diff bytes| diff % > >> >> 870728| 915000| 912560 > | > >> 41832| 4.8 > >> > > >> > > >> > I think you'll need to analyze that a bit more. First of all I > don't > >> > think the '+ping' tab is useful. What is is trying to achieve? > >> > >> >>> > >> >>> To show the difference of extra bytes if we add a ping app on top. > >> >>> > >> >>> > >> > - How was LWIP compiled? > >> > >> >>> > >> >>> It has a really huge configuration. I tried to turn off everything > off > >> >>> everything what can impact on size but still make http app work: > >> >>> #define LWIP_HAVE_LOOPIF0 > >> >>> #define LWIP_NETCONN0 > >> >>> #define LWIP_SOCKET 0 > >> >>> #define SO_REUSE0 > >> >>> #define LWIP_STATS 0 > >> >>> #define PPP_SUPPORT 0 > >> >>> > >> >>> Disabling loopback: > >> >>> #define LWIP_NETIF_LOOPBACK 0 > >> >>> can lower to 912288 bytes. > >> >>> > >> >>> And it's the same compilation option (optimization for size) as the > main > >> >>> u-boot. I will do more experiments, but I think the goal is not to > turn > >> >> off > >> >>> everything. > >> >>> > >> >>> > >> > - Was ipv6 supported? > >> > >> >>> > >> >>> No. I.e. when I sent results it was enabled on the compilation > stage but > >> >>> not used. I just checked that size
Re: [lwip-devel] [RFC PATCH 0/5] LWIP stack integration
Hi Maxim, On Tue, 6 Jun 2023 at 17:33, Maxim Uvarov 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: > 1. The original u-boot net stack (packet process and up layers) is 10k vs > lwip 40k (the very minimal settings were 30k). > 2. Network applications size is about the same 4kb for tftp original command > 5kb for lwip. > 3. It's quite easy to reuse LWIP examples to implement the same functionality > for the U-boot. > 4. 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? Thanks /Ilias > > BR, > Maxim. > > On Thu, 25 May 2023 at 02:18, Simon Goldschmidt wrote: >> >> Hi Maxim, Tom, >> >> On 24.05.2023 16:05, Maxim Uvarov wrote: >> > On Tue, 23 May 2023 at 03:23, Tom Rini wrote: >> > >> >> On Mon, May 22, 2023 at 12:40:49PM -0400, Maxim Uvarov wrote: >> >>> On Mon, 22 May 2023 at 10:20, Tom Rini wrote: >> >>> >> On Mon, May 22, 2023 at 04:33:57PM +0300, Ilias Apalodimas wrote: >> > Hi Maxim >> > >> > On Mon, 22 May 2023 at 12:01, Maxim Uvarov >> wrote: >> >> >> >> My measurements for binary after LTO looks like: >> >> >> >> U-boot WGET | LWIP WGET + ping | LWIP WGET| diff bytes| diff % >> >> 870728| 915000| 912560 | >> 41832| 4.8 >> > >> > >> > I think you'll need to analyze that a bit more. First of all I don't >> > think the '+ping' tab is useful. What is is trying to achieve? >> >> >>> >> >>> To show the difference of extra bytes if we add a ping app on top. >> >>> >> >>> >> > - How was LWIP compiled? >> >> >>> >> >>> It has a really huge configuration. I tried to turn off everything off >> >>> everything what can impact on size but still make http app work: >> >>> #define LWIP_HAVE_LOOPIF0 >> >>> #define LWIP_NETCONN0 >> >>> #define LWIP_SOCKET 0 >> >>> #define SO_REUSE0 >> >>> #define LWIP_STATS 0 >> >>> #define PPP_SUPPORT 0 >> >>> >> >>> Disabling loopback: >> >>> #define LWIP_NETIF_LOOPBACK 0 >> >>> can lower to 912288 bytes. >> >>> >> >>> And it's the same compilation option (optimization for size) as the main >> >>> u-boot. I will do more experiments, but I think the goal is not to turn >> >> off >> >>> everything. >> >>> >> >>> >> > - Was ipv6 supported? >> >> >>> >> >>> No. I.e. when I sent results it was enabled on the compilation stage but >> >>> not used. I just checked that size remains the same if IPv6 is not even >> >>> compiled. >> >>> >> >>> >> > - Can we strip it down even further? >> > >> >> >>> >> >>> There is always room for optimization. I think I tried to turn off >> >>> everything that is configurable with defines. I can play with disable IP >> >>> reassembly and things like that or figure out which functions have more >> >>> size and if it's possible to exclude them. >> >>> >> >>> >> > In general please give as much information as you can with what we >> > gain in functionality from LWIP with those extra bytes of code. >> >> >> >>> The main idea is to reuse a maintainable IP
Re: [lwip-devel] [RFC PATCH 0/5] LWIP stack integration
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 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) 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: 1. The original u-boot net stack (packet process and up layers) is 10k vs lwip 40k (the very minimal settings were 30k). 2. Network applications size is about the same 4kb for tftp original command 5kb for lwip. 3. It's quite easy to reuse LWIP examples to implement the same functionality for the U-boot. 4. 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). BR, Maxim. On Thu, 25 May 2023 at 02:18, Simon Goldschmidt wrote: > Hi Maxim, Tom, > > On 24.05.2023 16:05, Maxim Uvarov wrote: > > On Tue, 23 May 2023 at 03:23, Tom Rini wrote: > > > >> On Mon, May 22, 2023 at 12:40:49PM -0400, Maxim Uvarov wrote: > >>> On Mon, 22 May 2023 at 10:20, Tom Rini wrote: > >>> > On Mon, May 22, 2023 at 04:33:57PM +0300, Ilias Apalodimas wrote: > > Hi Maxim > > > > On Mon, 22 May 2023 at 12:01, Maxim Uvarov > wrote: > >> > >> My measurements for binary after LTO looks like: > >> > >> U-boot WGET | LWIP WGET + ping | LWIP WGET| diff bytes| diff % > >> 870728| 915000| 912560 | > 41832| 4.8 > > > > > > I think you'll need to analyze that a bit more. First of all I don't > > think the '+ping' tab is useful. What is is trying to achieve? > > >>> > >>> To show the difference of extra bytes if we add a ping app on top. > >>> > >>> > > - How was LWIP compiled? > > >>> > >>> It has a really huge configuration. I tried to turn off everything off > >>> everything what can impact on size but still make http app work: > >>> #define LWIP_HAVE_LOOPIF0 > >>> #define LWIP_NETCONN0 > >>> #define LWIP_SOCKET 0 > >>> #define SO_REUSE0 > >>> #define LWIP_STATS 0 > >>> #define PPP_SUPPORT 0 > >>> > >>> Disabling loopback: > >>> #define LWIP_NETIF_LOOPBACK 0 > >>> can lower to 912288 bytes. > >>> > >>> And it's the same compilation option (optimization for size) as the > main > >>> u-boot. I will do more experiments, but I think the goal is not to turn > >> off > >>> everything. > >>> > >>> > > - Was ipv6 supported? > > >>> > >>> No. I.e. when I sent results it was enabled on the compilation stage > but > >>> not used. I just checked that size remains the same if IPv6 is not even > >>> compiled. > >>> > >>> > > - Can we strip it down even further? > > > > >>> > >>> There is always room for optimization. I think I tried to turn off > >>> everything that is configurable with defines. I can play with disable > IP > >>> reassembly and things like that or figure out which functions have more > >>> size and if it's possible to exclude them. > >>> > >>> > > In general please give as much information as you can with what we > > gain in functionality from LWIP with those extra bytes of code. > > > >>> The main idea is to reuse a maintainable IP stack outside of U-boot. > >> LWIP > >>> can give a nice separation between IP stack code and network > application > >>> code. I.e. application should not take care about any TCP details > (SYN, > >>> ACK, retransmission, reassembly etc) and should open connection and use > >>> functions similar to recv() and send() to transfer data. Data means > >>> application data, no network packets. And LWIP allows > >>> us to do that. > >>> Because LWIP has an API similar to sockets, it has to be very easy to > >> port > >>> a linux application to LWIP. Then you can test it with a tap device. > Then > >>> copy sources to U-boot, add a small integration layer (cmd command to > >>> call), compile and use. > >>> > >>> So my suggestion was: > >>> - do not maintain new network stack code
Re: [lwip-devel] [RFC PATCH 0/5] LWIP stack integration
Hi Maxim, Tom, On 24.05.2023 16:05, Maxim Uvarov wrote: On Tue, 23 May 2023 at 03:23, Tom Rini wrote: On Mon, May 22, 2023 at 12:40:49PM -0400, Maxim Uvarov wrote: On Mon, 22 May 2023 at 10:20, Tom Rini wrote: On Mon, May 22, 2023 at 04:33:57PM +0300, Ilias Apalodimas wrote: Hi Maxim On Mon, 22 May 2023 at 12:01, Maxim Uvarov wrote: My measurements for binary after LTO looks like: U-boot WGET | LWIP WGET + ping | LWIP WGET| diff bytes| diff % 870728| 915000| 912560 | 41832| 4.8 I think you'll need to analyze that a bit more. First of all I don't think the '+ping' tab is useful. What is is trying to achieve? To show the difference of extra bytes if we add a ping app on top. - How was LWIP compiled? It has a really huge configuration. I tried to turn off everything off everything what can impact on size but still make http app work: #define LWIP_HAVE_LOOPIF0 #define LWIP_NETCONN0 #define LWIP_SOCKET 0 #define SO_REUSE0 #define LWIP_STATS 0 #define PPP_SUPPORT 0 Disabling loopback: #define LWIP_NETIF_LOOPBACK 0 can lower to 912288 bytes. And it's the same compilation option (optimization for size) as the main u-boot. I will do more experiments, but I think the goal is not to turn off everything. - Was ipv6 supported? No. I.e. when I sent results it was enabled on the compilation stage but not used. I just checked that size remains the same if IPv6 is not even compiled. - Can we strip it down even further? There is always room for optimization. I think I tried to turn off everything that is configurable with defines. I can play with disable IP reassembly and things like that or figure out which functions have more size and if it's possible to exclude them. In general please give as much information as you can with what we gain in functionality from LWIP with those extra bytes of code. The main idea is to reuse a maintainable IP stack outside of U-boot. LWIP can give a nice separation between IP stack code and network application code. I.e. application should not take care about any TCP details (SYN, ACK, retransmission, reassembly etc) and should open connection and use functions similar to recv() and send() to transfer data. Data means application data, no network packets. And LWIP allows us to do that. Because LWIP has an API similar to sockets, it has to be very easy to port a linux application to LWIP. Then you can test it with a tap device. Then copy sources to U-boot, add a small integration layer (cmd command to call), compile and use. So my suggestion was: - do not maintain new network stack code in the current U-boot. Use lwip sources as an external project. All bugs related to network stack go to lwip project first, then sync with U-boot. - maintain network apps code* or -- inside U-boot. Write our own code for application and maintain it inside U-boot. -- inside LWIP. Add examples to LWIP which are suitable for both U-boot and LWIP. * Let's define a U-boot network application as a cmd command. It might be ping, wget (http or https download), telnet, arp dns etc.. Let's consider the real use case, like HTTPS download client. We need to enable TLS connection, validate certificates, then do http download. Looking at the current code of wget command it's quite difficult to implement this due to the application having some protol level things. On the other side we can find embedTLS examples to do https download on sockets. If LWIP socket API is ported then the only thing you need to do is change socket() -> lwip_socket(), recv()->lwip_recv(), send()->lwip_send() and etc, even function names are similar. If LWIP socket API is not supported, then use callback API for recv() and send(), which are also easy. So yes we add extra bytes, but that will allow us to write more complex apps, use standard debug tools, use applications with very minimal integration changes, use help from the LWIP community to fix protocol bugs, etc.. Bunch of things already implemented there: - ipv6 - dhcp - snmp - igmp - dns - tcp and udp and raw. - loopback - netconn - socket - stats - ppp (I just followed configurable defines). And please make sure to disable the previous support, my guess fro that much growth is that you didn't. # CONFIG_PROT_TCP is not set # CONFIG_PROT_UDP is not set # CONFIG_UDP_CHECKSUM is not set # CONFIG_UDP_FUNCTION_FASTBOOT is not set # CONFIG_CMD_WGET is not set I think you need to step back and figure out a better way to measure the size change and growth. I am not interested in a path that long term means two networking stacks in U-Boot. I am not interested in massively growing the overall binary size for every platform. Given how much larger just TCP support is, that's strongly implying a huge growth for the older use cases too. But I
