[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [lwip-devel] [RFC PATCH 0/5] LWIP stack integration
|
From: |
Ilias Apalodimas |
|
Subject: |
Re: [lwip-devel] [RFC PATCH 0/5] LWIP stack integration |
|
Date: |
Thu, 8 Jun 2023 20:52:55 +0300 |
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.
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 <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