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
signature.asc
Description: PGP signature