[RFC PATCH 0/5] LWIP stack integration

[Tom Rini]

On Mon, May 22, 2023 at 12:40:49PM -0400, Maxim Uvarov wrote:
> On Mon, 22 May 2023 at 10:20, Tom Rini <trini at 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 at 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20230522/00b23759/attachment.sig>