[RFC PATCH 0/5] LWIP stack integration

[Tom Rini]

On Mon, May 15, 2023 at 11:25:58AM -0400, Maxim Uvarov wrote:
> On Thu, 11 May 2023 at 09:52, Tom Rini <trini at konsulko.com> wrote:
> 
> > On Fri, May 05, 2023 at 10:25:24AM +0000, Maxim Uvarov wrote:
> >
> > > Greetings,
> > >
> > > This RFC patchset is an attempt to try to use an already existing IP
> > network stack inside U-boot.
> > > U-Boot recently got basic TCP/IP support, implementing wget, but in
> > order to get a full IP stack
> > > with new features (e.g ipv6), it would be preferable to use an
> > established embedded ip library,
> > > instead of rewriting the code from scratch.
> > >
> > > For this experiment LWIP network stack was selected:
> > > https://savannah.nongnu.org/git/?group=lwip
> > >
> > > LWIP main features include:
> > > - Protocols: IP, IPv6, ICMP, ND, MLD, UDP, TCP, IGMP, ARP, PPPoS, PPPoE
> > > - DHCP client, DNS client (incl. mDNS hostname resolver), AutoIP/APIPA
> > (Zeroconf),
> > >   SNMP agent (v1, v2c, v3, private MIB support & MIB compiler)
> > > - APIs: specialized APIs for enhanced performance, optional
> > Berkeley-alike socket API
> > > - Extended features: IP forwarding over multiple network interfaces, TCP
> > congestion control,
> > >   RTT estimation and fast recovery/fast retransmit
> > > - Addon applications: HTTP(S) server, SNTP client, SMTP(S) client, ping,
> > NetBIOS nameserver,
> > >   mDNS responder, MQTT client, TFTP server.
> > >
> > > This RFC work is a demo to enable lwIP (lightweight IP) which is a
> > widely used open-source
> > > TCP/IP stack designed for embedded systems for U-boot. That will allow
> > using already
> > > written network applications for microcontrollers.
> > >
> > > lwIP is licensed under a BSD-style license:
> > http://lwip.wikia.com/wiki/License.
> > > Which should be compatible with u-boot.
> > >
> > > In the current RFC I tried to use minimal changes to better see how LWIP
> > code can be embedded into
> > > U-boot. Patches implement ping and wget commands work. Both commands are
> > currently copy pasting and
> > > reusing lwIP examples.  Whether we want to add the final application in
> > U-Boot or lwIP is up to
> > > discussion, but the current approach was the easiest one for an RFC.
> >
> > I'm honestly not sure this is the most useful way of doing an RFC.  The
> > long term goal would be that we replace our existing net/ with lwIP,
> > yes? So what I'd see as more valuable is what it looks like to limit
> > yourself to either sandbox or some QEMU target, disable the current
> > network stack, and instead use lwIP to support just cmd/net.c so that
> > the scope of the conversion is visible.  Then the size comparison you do
> > should be between platform + net + cmd/net.c (and the rest of networking
> > turned off) and platform + lwip + cmd/net.c converted.
> >
> > --
> > Tom
> >
> 
> Is there any acceptance criteria for size? If we say that additing lwip
> will add about 48kb and removing current code will also release some kbs.
> How size is critical here or it's just numbers good to know?

Well, the text portion of a current sandbox build (with LTO off, so
adding up sizes is easier to do quickly) net/ is 46kB.  But that
includes v6 and fastboot and so on.

So, it's a matter of discussion. If replacing the network stack but
maintaining the same level of functionality causes us to grow by single
digit kilobytes, we can maybe justify it due to easier to maintain. If
it's smaller, that's great and an argument in favor of it. But if we're
growing everything by tens of kilobytes, that's a lot harder to justify
but maybe shows we need to work with upstream as perhaps some things
need to be more configurable, or otherwise something to investigate.

-- 
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/20230515/f9eb5069/attachment.sig>