On Thu, Jun 8, 2023 at 6:56 PM Ilias Apalodimas <ilias.apalodi...@linaro.org> wrote: > > Thanks Maxim, > > On Thu, 8 Jun 2023 at 13:14, Maxim Uvarov <maxim.uva...@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 <tr...@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 <tr...@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 <tr...@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.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_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