[RFC PATCH 0/5] LWIP stack integration

[Maxim Uvarov]

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

BR,
Maxim.

>
> --
> Tom
>