[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [lwip-devel] [RFC PATCH 0/5] LWIP stack integration
|
From: |
Peter Robinson |
|
Subject: |
Re: [lwip-devel] [RFC PATCH 0/5] LWIP stack integration |
|
Date: |
Fri, 9 Jun 2023 08:37:24 +0100 |
On Thu, Jun 8, 2023 at 6:56 PM Ilias Apalodimas
<ilias.apalodimas@linaro.org> wrote:
>
> Thanks Maxim,
>
> On Thu, 8 Jun 2023 at 13:14, Maxim Uvarov <maxim.uvarov@linaro.org> 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
> > 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
> > tcp_output_control_segment_netif - 164 +164
> > send_error.isra - 164 +164
> > do_ops - 164 +164
> > raw_sendto - 160 +160
> > pbuf_realloc - 160 +160
> > pbuf_free - 160 +160
> > do_lwip_wget - 160 +160
> > do_lwip_tftp - 160 +160
> > tftp_init_common - 156 +156
> > tcp_rst_netif - 152 +152
> > udp_sendto - 144 +144
> > tftp_tmr - 144 +144
> > tcp_rst - 144 +144
> > uboot_lwip_if_init - 140 +140
> > tcp_pcb_remove - 140 +140
> > tcp_pbuf_prealloc - 140 +140
> > sys_timeout_abs - 140 +140
> > lwip_tftp - 140 +140
> > netif_do_set_ipaddr.isra - 136 +136
> > ip4_route - 136 +136
> > tcp_netif_ip_addr_changed - 132 +132
> > resend_data.isra - 132 +132
> > inet_chksum_pbuf - 132 +132
> > tcp_output_control_segment - 128 +128
> > pbuf_memfind - 128 +128
> > lwip_standard_chksum - 128 +128
> > tcp_rexmit_fast - 124 +124
> > tcp_new_port - 124 +124
> > tcp_close_shutdown_fin - 124 +124
> > pbuf_add_header_impl - 124 +124
> > tcp_send_empty_ack - 120 +120
> > httpc_create_request_string.constprop.isra - 120 +120
> > tftp_get - 116 +116
> > tcp_recved - 116 +116
> > tcp_pcb_purge - 116 +116
> > tftp_write - 112 +112
> > pbuf_free_header - 112 +112
> > httpc_tcp_connected - 112 +112
> > tftp_error - 108 +108
> > send_ack.isra - 108 +108
> > low_level_input.constprop - 108 +108
> > tcp_input_delayed_close - 104 +104
> > close_handle - 100 +100
> > sys_untimeout - 96 +96
> > memp_pools - 96 +96
> > tcp_keepalive - 92 +92
> > ip4_addr_isbroadcast_u32 - 92 +92
> > init_packet - 92 +92
> > tcp_kill_state - 88 +88
> > raw_new - 88 +88
> > ping_raw_init - 88 +88
> > lwip_ping_init - 88 +88
> > udp_sendto_if - 84 +84
> > tcp_update_rcv_ann_wnd - 84 +84
> > tcp_recv_null - 84 +84
> > pbuf_remove_header - 84 +84
> > pbuf_alloc_reference - 84 +84
> > udp_remove - 80 +80
> > tcp_get_next_optbyte - 80 +80
> > pbuf_alloced_custom - 80 +80
> > ip4_input_accept - 80 +80
> > httpc_close - 80 +80
> > etharp_free_entry - 80 +80
> > uboot_lwip_poll - 76 +76
> > tcpip_tcp_timer - 76 +76
> > udp_netif_ip_addr_changed - 72 +72
> > uboot_netif - 72 +72
> > tcp_output_alloc_header.constprop - 72 +72
> > raw_netif_ip_addr_changed - 72 +72
> > tcpip_try_callback - 68 +68
> > tcp_timer_needed - 68 +68
> > tcp_seg_copy - 68 +68
> > tcp_netif_ip_addr_changed_pcblist - 68 +68
> > ping_timeout - 68 +68
> > ethernetif_input - 68 +68
> > udp_new - 64 +64
> > pbuf_try_get_at - 64 +64
> > sys_timeout - 60 +60
> > pbuf_clone - 60 +60
> > tcp_seg_free - 56 +56
> > pbuf_cat - 56 +56
> > netif_get_by_index - 56 +56
> > low_level_output - 56 +56
> > _u_boot_list_2_cmd_2_lwipinfo - 56 +56
> > _u_boot_list_2_cmd_2_lwip - 56 +56
> > tftp_state 4 56 +52
> > tcp_tmr - 52 +52
> > tcp_rexmit_rto - 52 +52
> > tcp_segs_free - 48 +48
> > tcp_eff_send_mss_netif - 48 +48
> > pbuf_skip_const - 48 +48
> > ipfrag_free_pbuf_custom - 48 +48
> > httpc_tcp_poll - 48 +48
> > tcp_free_ooseq - 44 +44
> > tcp_close - 44 +44
> > pbuf_free_ooseq_callback - 44 +44
> > netif_issue_reports - 44 +44
> > ip_reass_dequeue_datagram - 44 +44
> > httpc_get_internal_addr - 44 +44
> > tftp_read - 40 +40
> > tftp - 40 +40
> > ip_data - 40 +40
> > etharp_request - 40 +40
> > do_lwip_info - 40 +40
> > ulwip_timeout_handler - 36 +36
> > raw_bind - 36 +36
> > memp_malloc - 36 +36
> > ip4_output_if - 36 +36
> > tcp_pcb_lists - 32 +32
> > pbuf_header_force - 32 +32
> > pbuf_clen - 32 +32
> > netif_set_up - 32 +32
> > netif_set_link_up - 32 +32
> > inseg - 32 +32
> > inet_chksum - 32 +32
> > tcp_next_iss - 28 +28
> > pbuf_get_at - 28 +28
> > httpc_tcp_err - 28 +28
> > do_lwip_init - 28 +28
> > tcp_rexmit_rto_commit - 24 +24
> > sys_now - 24 +24
> > settings - 24 +24
> > pbuf_copy - 24 +24
> > pbuf_chain - 24 +24
> > memp_free - 24 +24
> > __func__ 1243 1266 +23
> > ulwip_exit - 20 +20
> > tcp_trigger_input_pcb_close - 20 +20
> > tcp_poll - 20 +20
> > ping_send_now - 20 +20
> > pbuf_ref - 20 +20
> > str - 16 +16
> > ip4addr_ntoa - 16 +16
> > daddr - 16 +16
> > tcp_backoff - 13 +13
> > ulwip_loop_set - 12 +12
> > ulwip_in_loop - 12 +12
> > ulwip_enabled - 12 +12
> > ulwip_app_get_err - 12 +12
> > udp_recv - 12 +12
> > tftp_init_client - 12 +12
> > tcp_sent - 12 +12
> > tcp_recv - 12 +12
> > tcp_free - 12 +12
> > tcp_err - 12 +12
> > tcp_arg - 12 +12
> > net_process_received_packet 800 812 +12
> > icmp_time_exceeded - 12 +12
> > icmp_dest_unreach - 12 +12
> > udp_pcbs - 8 +8
> > tftp_open - 8 +8
> > tftp_close - 8 +8
> > tcphdr_opt2 - 8 +8
> > tcphdr - 8 +8
> > tcp_tw_pcbs - 8 +8
> > tcp_new - 8 +8
> > tcp_listen_pcbs - 8 +8
> > tcp_input_pcb - 8 +8
> > tcp_bound_pcbs - 8 +8
> > tcp_active_pcbs - 8 +8
> > tcp_abort - 8 +8
> > recv_data - 8 +8
> > reassdatagrams - 8 +8
> > raw_recv - 8 +8
> > raw_pcbs - 8 +8
> > ping_target - 8 +8
> > ping_pcb - 8 +8
> > pbuf_add_header - 8 +8
> > next_timeout - 8 +8
> > netif_null_output_ip4 - 8 +8
> > netif_list - 8 +8
> > netif_default - 8 +8
> > lwip_htons - 8 +8
> > lwip_htonl - 8 +8
> > httpc_tcp_sent - 8 +8
> > tcp_persist_backoff - 7 +7
> > ethzero - 6 +6
> > ethbroadcast - 6 +6
> > ulwip_app_err - 4 +4
> > udp_new_ip_type - 4 +4
> > uboot_net_use_lwip - 4 +4
> > tcpip_tcp_timer_active - 4 +4
> > tcp_ticks - 4 +4
> > seqno - 4 +4
> > mem_trim - 4 +4
> > mem_malloc - 4 +4
> > mem_free - 4 +4
> > loop_lwip - 4 +4
> > iss - 4 +4
> > ip_target - 4 +4
> > ip_chksum_pseudo - 4 +4
> > ip_addr_any - 4 +4
> > httpc_init_connection - 4 +4
> > ackno - 4 +4
> > udp_port - 2 +2
> > tcplen - 2 +2
> > tcphdr_optlen - 2 +2
> > tcphdr_opt1len - 2 +2
> > tcp_port - 2 +2
> > tcp_optidx - 2 +2
> > recv_acked - 2 +2
> > ping_seq_num - 2 +2
> > memp_UDP_PCB - 2 +2
> > memp_TCP_SEG - 2 +2
> > memp_TCP_PCB_LISTEN - 2 +2
> > memp_TCP_PCB - 2 +2
> > memp_TCPIP_MSG_INPKT - 2 +2
> > memp_TCPIP_MSG_API - 2 +2
> > memp_SYS_TIMEOUT - 2 +2
> > memp_REASSDATA - 2 +2
> > memp_RAW_PCB - 2 +2
> > memp_PBUF_POOL - 2 +2
> > memp_PBUF - 2 +2
> > memp_FRAG_PBUF - 2 +2
> > ip_reass_pbufcount - 2 +2
> > ip_id - 2 +2
> > tcp_timer_ctr - 1 +1
> > tcp_timer - 1 +1
> > tcp_active_pcbs_changed - 1 +1
> > recv_flags - 1 +1
> > pbuf_free_ooseq_pending - 1 +1
> > netif_num - 1 +1
> > flags - 1 +1
> > etharp_cached_entry - 1 +1
> > supported_nfs_versions 1 - -1
> > retry_action 1 - -1
> > net_boot_file_name_explicit 1 - -1
> > dhcp_option_overload 1 - -1
> > tftp_windowsize 2 - -2
> > tftp_window_size_option 2 - -2
> > tftp_next_ack 2 - -2
> > tftp_last_nack 2 - -2
> > tftp_block_size_option 2 - -2
> > tftp_block_size 2 - -2
> > ping_seq_number 2 - -2
> > last_op 2 - -2
> > env_flags_vartype_rep 7 5 -2
> > linefeed 3 - -3
> > wget_timeout_count 4 - -4
> > wget_loop_state 4 - -4
> > web_server_ip 4 - -4
> > timeout_count_max 4 - -4
> > timeout_count 4 - -4
> > tftp_timeout_count_max 4 - -4
> > tftp_remote_port 4 - -4
> > tftp_remote_ip 4 - -4
> > tftp_our_port 4 - -4
> > saved_tftp_block_size_option 4 - -4
> > retry_tcp_seq_num 4 - -4
> > retry_tcp_ack_num 4 - -4
> > retry_len 4 - -4
> > pkt_q_idx 4 - -4
> > packets 4 - -4
> > our_port 4 - -4
> > nfs_timeout_count 4 - -4
> > nfs_state 4 - -4
> > nfs_server_port 4 - -4
> > nfs_server_mount_port 4 - -4
> > nfs_server_ip 4 - -4
> > nfs_our_port 4 - -4
> > nfs_offset 4 - -4
> > nfs_len 4 - -4
> > nfs_download_state 4 - -4
> > net_ping_ip 4 - -4
> > net_dns_server 4 - -4
> > net_boot_file_expected_size_in_blocks 4 - -4
> > last_reg_lo 4 - -4
> > last_reg_hi 4 - -4
> > last_mask 4 - -4
> > last_data 4 - -4
> > last_addr_lo 4 - -4
> > last_addr_hi 4 - -4
> > initial_data_seq_num 4 - -4
> > http_ok 4 - -4
> > fs_mounted 4 - -4
> > filefh3_length 4 - -4
> > eth_common_init 4 - -4
> > dummy_handler 8 4 -4
> > dhcp_state 4 - -4
> > dhcp_server_ip 4 - -4
> > dhcp_leasetime 4 - -4
> > current_wget_state 4 - -4
> > bootp_try 4 - -4
> > bootp_num_ids 4 - -4
> > http_eom 5 - -5
> > bootfile1 5 - -5
> > timeout_ms 8 - -8
> > time_taken_max 8 - -8
> > time_start 16 8 -8
> > tftp_prev_block 8 - -8
> > tftp_load_size 8 - -8
> > tftp_load_addr 8 - -8
> > tftp_cur_block 8 - -8
> > tftp_block_wrap_offset 8 - -8
> > tftp_block_wrap 8 - -8
> > rpc_id 8 - -8
> > nfs_path 8 - -8
> > nfs_filename 8 - -8
> > miiphy_is_1000base_x 8 - -8
> > init_sequence_r 264 256 -8
> > image_url 8 - -8
> > distro_pxe_check 8 - -8
> > current_mii 8 - -8
> > content_length 8 - -8
> > bootp_timeout 8 - -8
> > bootp_start 8 - -8
> > tcp_get_tcp_state 12 - -12
> > do_wget 12 - -12
> > do_tftpb 12 - -12
> > do_nfs 12 - -12
> > do_dhcp 12 - -12
> > do_bootp 12 - -12
> > default_filename 13 - -13
> > bootfile3 14 - -14
> > content_len 15 - -15
> > reg_2_desc_tbl 16 - -16
> > pkt_q 16 - -16
> > mii_devs 16 - -16
> > bootp_ids 16 - -16
> > miiphy_get_current_dev 20 - -20
> > tcp_set_tcp_handler 24 - -24
> > pxe_default_paths 24 - -24
> > net_set_udp_handler 24 - -24
> > net_check_prereq 256 232 -24
> > miiphy_init 28 - -28
> > ping_timeout_handler 32 - -32
> > net_nis_domain 32 - -32
> > net_hostname 32 - -32
> > distro_bootmeth_pxe_ids 32 - -32
> > dirfh 32 - -32
> > initr_net 36 - -36
> > distro_bootmeth_pxe_bind 36 - -36
> > ip_to_string 40 - -40
> > distro_bootmeth_pxe_ops 40 - -40
> > net_send_udp_packet 44 - -44
> > label_boot 1944 1900 -44
> > env_flags_validate 632 588 -44
> > reg_3_desc_tbl 48 - -48
> > do_get_tftp 56 - -56
> > cmd_net 56 - -56
> > _u_boot_list_2_cmd_2_wget 56 - -56
> > _u_boot_list_2_cmd_2_tftpboot 56 - -56
> > _u_boot_list_2_cmd_2_pxe 56 - -56
> > _u_boot_list_2_cmd_2_ping 56 - -56
> > _u_boot_list_2_cmd_2_nfs 56 - -56
> > _u_boot_list_2_cmd_2_net 56 - -56
> > _u_boot_list_2_cmd_2_mii 56 - -56
> > _u_boot_list_2_cmd_2_dhcp 56 - -56
> > _u_boot_list_2_cmd_2_bootp 56 - -56
> > net_loop 652 592 -60
> > net_eth_hdr_size 60 - -60
> > bootp_reset 60 - -60
> > net_root_path 64 - -64
> > filefh 64 - -64
> > do_bootvx 816 748 -68
> > miiphy_set_current_dev 72 - -72
> > basename 72 - -72
> > pxe_get_file_size 76 - -76
> > copy_filename 76 - -76
> > distro_pxe_getfile 80 - -80
> > tftp_init_load_addr 92 - -92
> > miiphy_read 92 - -92
> > extract_range 92 - -92
> > miiphy_write 96 - -96
> > miiphy_get_active_dev 96 - -96
> > distro_pxe_read_file 96 - -96
> > wget_fail 104 - -104
> > skip_num 104 - -104
> > miiphy_get_dev_by_name 104 - -104
> > dump_field 104 - -104
> > do_bdinfo 432 328 -104
> > bootp_timeout_handler 104 - -104
> > nfs_timeout_handler 108 - -108
> > cmd_pxe_sub 112 - -112
> > nfs_umountall_req 120 - -120
> > _u_boot_list_2_driver_2_bootmeth_pxe 120 - -120
> > do_ping 124 - -124
> > tftp_filename 128 - -128
> > reg_9_desc_tbl 128 - -128
> > reg_10_desc_tbl 128 - -128
> > distro_pxe_boot 128 - -128
> > tftp_timeout_handler 132 - -132
> > do_pxe 132 - -132
> > nfs_umountall_reply 136 - -136
> > lmb_get_free_size 136 - -136
> > format_mac_pxe 136 - -136
> > miiphy_listdev 144 - -144
> > efi_net_set_dhcp_ack 144 - -144
> > wget_timeout_handler 148 - -148
> > nfs_mount_reply 148 - -148
> > dhcp_packet_process_options 148 - -148
> > eth_validate_ethaddr_str 152 - -152
> > do_pxe_get 156 - -156
> > reg_0_desc_tbl 160 - -160
> > net_parse_bootfile 160 - -160
> > miiphy_info 160 - -160
> > get_pxelinux_path 160 - -160
> > do_net 164 - -164
> > net_auto_load 172 - -172
> > do_net_list 176 - -176
> > rpc_lookup_reply 180 - -180
> > nfs_readlink_req 184 - -184
> > nfs_mount_req 188 - -188
> > reg_5_desc_tbl 192 - -192
> > reg_4_desc_tbl 192 - -192
> > miiphy_speed 200 - -200
> > miiphy_duplex 200 - -200
> > nfs_read_req 224 - -224
> > do_pxe_boot 248 - -248
> > reg_1_desc_tbl 256 - -256
> > mii_reg_desc_tbl 256 - -256
> > nfs_send 260 - -260
> > wget_start 268 - -268
> > ping_start 276 - -276
> > nfs_lookup_reply 280 - -280
> > rpc_req 300 - -300
> > eth_initialize 300 - -300
> > distro_pxe_read_bootflow 300 - -300
> > nfs_readlink_reply 328 - -328
> > nfs_lookup_req 328 - -328
> > ping_receive 332 - -332
> > pxe_get 376 - -376
> > nfs_read_reply 396 - -396
> > wget_send_stored 444 - -444
> > nfs_start 468 - -468
> > dhcp_process_options 508 - -508
> > tftp_send 560 - -560
> > nfs_handler 580 - -580
> > bootp_request 612 - -612
> > dhcp_extended 616 - -616
> > netboot_common 632 - -632
> > default_environment 4444 3800 -644
> > tftp_start 912 - -912
> > dhcp_handler 1000 - -1000
> > wget_handler 1092 - -1092
> > tftp_handler 1304 - -1304
> > nfs_path_buff 2048 - -2048
> > do_mii 2124 - -2124
> > Total: Before=722283, After=738425, chg +2.23%
> >
> >
> >
> > On Thu, 8 Jun 2023 at 02:07, Tom Rini <trini@konsulko.com> wrote:
> >>
> >> 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 <trini@konsulko.com> wrote:
> >> > >
> >> > > > On Mon, May 22, 2023 at 12:40:49PM -0400, Maxim Uvarov wrote:
> >> > > > > On Mon, 22 May 2023 at 10:20, Tom Rini <trini@konsulko.com> 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.uvarov@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_LOOPIF 0
> >> > > > > #define LWIP_NETCONN 0
> >> > > > > #define LWIP_SOCKET 0
> >> > > > > #define SO_REUSE 0
> >> > > > > #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 also suspect given the overall reputation that LWIP enjoys,
> >> > > > there's something amiss here.
> >> > > >
> >> > > > --
> >> > > > Tom
> >> > > >
> >> > >
> >> > > +cc lwip-devel@ mailing list, maybe they have something to add.
> >> >
> >> > I do think using lwIP instead of "inventing yet another IP stack" is a
> >> > good idea! However, in terms of code size, lwIP will lose against what's
> >> > in U-Boot at present. And this is only natural, as lwIP is a "full-size"
> >> > stack supporting multiple concurrently running applications while the
> >> > current IP stack in U-Boot is rather "crippled" down to just what the
> >> > implementor needed at the time of writing.
> >> >
> >> > One example of this is that (if I remember correctly), U-Boot only has
> >> > one single network packet buffer, while lwIP has support for multiple
> >> > buffers. When speaking of TCP (forgive me if I'm wrong, I've lost track
> >> > of that development in U-Boot about 3 years ago), we're comparing "we
> >> > have implemented everything we need so that it just kind of works" to
> >> > "we can easily add a HTTPS client to download something over the
> >> > internet just by enabling more compile options".
> >> >
> >> > Also, when comparing lwIP to U-Boot TCP code size, keep in mind that
> >> > U-Boot TCP (at least that of some years ago) is far from complete when
> >> > compared to lwIP!
> >> >
> >> > lwIP is meant to be highly configurable and we're always open to add yet
> >> > more options to leave out more code when it's not needed. However, I
> >> > think there are some design decisions that will make lwIP larger than
> >> > the current IP stack in U-Boot. To me, that's a natural result of having
> >> > a "generic code" approach vs "developed to our needs". However, while
> >> > DHCP + BOOTP and even a simple network console was rather easy to
> >> > implement, I would not recommend implementing your own HTTPS download
> >> > but rather using the existing lwIP + apps for that.
> >> >
> >> > In the end, I cannot take the decision from you. In my opinion, lwIP
> >> > would be the better decision in terms of future work load and
> >> > compatibility, but in the short run, it *will* lead to bigger binaries
> >> > at least in some setups. And I do know from my past that it sometimes
> >> > has been a pain to try and stuff a new U-Boot release into the existing
> >> > space of flash or RAM, so that's not an easy decision.
> >> >
> >> > If you do take the lwIP approach however, let us know if we can help!
> >>
> >> Given Maxim's more recent experiments, I'm sure we can come up with
> >> something that works overall. There's hopefully a place or two U-Boot
> >> people can help introduce a tunable or two to lwIP to bring some sizes
> >> down. But I think it's overall looking to be the right direction.
> >>
> >> --
> >> Tom