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. 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 > 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