Re: [lwip-devel] [RFC PATCH 0/5] LWIP stack integration

Ilias asked to make more clear results to compare the original stack and LWIP stack. So the difference between the current U-boot stack and the LWIP stack with 3 network commands is:

a) 18Kb - ls -lh size

b) 15Kb - bloat-o-meter script total line report.

BOM=linux/scripts/bloat-o-meter (script)

1. 893K - U-boot CMD_NET=n
2. 928K - U-boot CMD_NET=y TFTP=y PING=y WGET=y
BOM 1-2: Total: Before=692286, After=722283, chg +4.33%
3. 940K - U-boot CMD_NET=n, LWIP_TFTP=y LWIP_PING=y LWIP_PING=y
BOM 1-3: Total: Before=692286, After=738425, chg +6.66%

BOM 2-3:

add/remove: 287/203 grow/shrink: 3/11 up/down: 43459/-27317 (16142)
Function old new delta
tcp_input - 3588 +3588
tcp_receive - 2884 +2884
ip4_reass - 1760 +1760
tcp_output - 1400 +1400
tcp_write - 1300 +1300
tcp_slowtmr - 1172 +1172
httpc_tcp_recv - 1044 +1044
tftp_recv - 888 +888
ip4_input - 700 +700
ip4_frag - 632 +632
icmp_input - 604 +604
udp_input - 596 +596
etharp_input - 512 +512
tcp_split_unsent_seg - 500 +500
ip4addr_aton - 492 +492
tcp_alloc - 484 +484
ip4_output_if_src - 476 +476
tcp_close_shutdown - 448 +448
etharp_query - 436 +436
httpc_init_connection_common.constprop - 416 +416
udp_sendto_if_src - 408 +408
etharp_output - 404 +404
arp_table - 400 +400
tcp_connect - 396 +396
pbuf_alloc - 376 +376
etharp_find_entry - 372 +372
tcp_abandon - 368 +368
tcp_zero_window_probe - 356 +356
raw_sendto_if_src - 328 +328
pbuf_copy_partial_pbuf - 328 +328
ip_reass_free_complete_datagram - 328 +328
tcp_create_segment - 300 +300
raw_input - 292 +292
uboot_lwip_init - 284 +284
ethernet_input - 284 +284
etharp_raw - 284 +284
tcp_output_alloc_header_common.constprop - 280 +280
cmds - 280 +280
udp_bind - 276 +276
tcp_oos_insert_segment - 276 +276
ip_reass_remove_oldest_datagram - 272 +272
icmp_send_response - 268 +268
netif_add - 260 +260
ping_send - 244 +244
tcp_rexmit - 232 +232
tcp_parseopt - 220 +220
tcp_free_acked_segments.constprop - 220 +220
send_request - 220 +220
inet_chksum_pseudo - 216 +216
ip4addr_ntoa_r - 212 +212
do_lwip_ping - 212 +212
tcp_enqueue_flags - 208 +208
etharp_output_to_arp_index - 208 +208
netif_set_addr - 204 +204
tcp_fasttmr - 200 +200
tcp_rexmit_rto_prepare - 196 +196
tcp_process_refused_data - 196 +196
send_data - 196 +196
lwip_wget - 192 +192
ethernet_output - 192 +192
ping_recv - 188 +188
pbuf_memcmp - 184 +184
pbuf_copy_partial - 184 +184
httpc_free_state - 180 +180
tcp_send_fin - 172 +172
httpc_recv - 168 +168
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

From:	Maxim Uvarov
Subject:	Re: [lwip-devel] [RFC PATCH 0/5] LWIP stack integration
Date:	Thu, 8 Jun 2023 16:14:25 +0600