From: Tom Rini <trini@konsulko.com>
To: Simon Glass <sjg@chromium.org>
Cc: Ilias Apalodimas <ilias.apalodimas@linaro.org>,
Maxim Uvarov <maxim.uvarov@linaro.org>,
Simon Goldschmidt <goldsimon@gmx.de>,
u-boot@lists.denx.de, pbrobinson@redhat.com,
joe.hershberger@ni.com, rfried.dev@gmail.com,
lwip-devel <lwip-devel@nongnu.org>
Subject: Re: [lwip-devel] [RFC PATCH 0/5] LWIP stack integration
Date: Sun, 11 Jun 2023 14:34:52 -0400 [thread overview]
Message-ID: <20230611183452.GC835503@bill-the-cat> (raw)
In-Reply-To: <CAPnjgZ33KLEy7G+GVFGN2OTA5AcC+g3T_s24fcm3uXUfmMDw2A@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 3548 bytes --]
On Sun, Jun 11, 2023 at 09:24:14AM +0100, Simon Glass wrote:
> Hi,
>
> On Wed, 7 Jun 2023 at 10:47, Ilias Apalodimas
> <ilias.apalodimas@linaro.org> wrote:
> >
> > Hi Maxim,
> >
> > On Tue, 6 Jun 2023 at 17:33, Maxim Uvarov <maxim.uvarov@linaro.org> wrote:
> > >
> > > Greetings,
> > >
> > > I implemented the tftp client (that was quick due to lwip has example app for tftp), and did some more measurements.
> > > I uploaded patches here if somebody want to do his own measurements:
> > > https://github.com/muvarov/uboot-lwip
> > >
> > > measure 1:
> > > 976K - total (total means lwip with all 3 commands ping, tftp, wget)
> > > 971K - total - tftp (total, but disable/minus tftp)
> > > 965K - total - tftp - wget (disable tftp and wget)
> > > 963K - total - tftp - wget - ping (disable tftp, wget, ping)
> > > 931K - no lwip
> > >
> > > result 1: lwip tftp (+ udp protocol) protocol 976-971k = 5kb
> > > result 2: lwip ping command 965- 963 = 2kb
> > > result 3: lwip wget command 971- 965 = 6kb
> > > result 4: lwip core stack with apps 976 - 931 = 45kb
> >
> > So tftp = 5kb, wget = 6kb ping =2kb and lwip = 32kb
> >
> > >
> > > measure 2:
> > > 890K - no CONFIG_NET_CMD
> > > 930K - + lwip tftp only
> > > 937K - + full lwip (ping wget tftp)
> > >
> > > result 1: 937-890=47kb ( lwip + all 3 commands)
> > > result 2: 937-930=7kb (ping and lwip command)
> >
> > I am not sure I understand this measurement. How is this different
> > from measurement 1 where the entire binary was 976K?
> >
> > >
> > > measure 3:
> > > 904K - no lwip, CMD_NET_TFTP=y
> > > 900K - no lwip, CMD_NET_TFTP=n
> > > result 1: original u-boot tftp command 904-900=4kb
> > > 890K - no lwip, CMD_NET=n
> > > result 2: 900-890=10k original u-boot net/IP stack.
> > >
> > > My findings for all that measurements and lwip configuration:
> > > 1. The original u-boot net stack (packet process and up layers) is 10k vs lwip 40k (the very minimal settings were 30k).
> > > 2. Network applications size is about the same 4kb for tftp original command 5kb for lwip.
> > > 3. It's quite easy to reuse LWIP examples to implement the same functionality for the U-boot.
> > > 4. I still think that there are other criterias which might have more priority than size (bug free code, code reuse, development speed, compatible API to posix and etc).
> >
> > Yes, there are other criteria and certainly having a complete network
> > stack might be worth it in many cases, but we need to keep in mind
> > 30kb might be a lot for some systems.
> >
> > I personally think this is decent and we can optimize lwip more in the
> > future. Tom, Simon, how about adding lwip as 'experimental' and
> > making it depend on !CMD_NET or something similar?
>
> That seems OK to me, but we don't really want two network stacks, so
> we'd need to set an expectation that we would move to lwip.
Yes, we'll need to move on to evaluating that once we can show and use
lwip as a replacement for most cases.
> I wonder why it is so large? I saw mention of it supporting multiple
> buffers and perhaps having a fuller implementation of the protocols.
> But it makes U-Boot's stack seem super-slim in comparison. I wonder if
> lwip could support just a single buffer and reduced functionality in
> other areas?
Well, right. Seeing what space related tuneables we can introduce
and/or further tune down will be of interest. But that will be easier
to do once it's easier to try out lwip in U-Boot itself.
--
Tom
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]
next prev parent reply other threads:[~2023-06-11 18:35 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-05-05 10:25 [RFC PATCH 0/5] LWIP stack integration Maxim Uvarov
2023-05-05 10:25 ` [RFC PATCH 1/5] add lwip-external submodule Maxim Uvarov
2023-05-08 14:43 ` Simon Glass
2023-05-10 7:40 ` Ilias Apalodimas
2023-05-10 14:46 ` Peter Robinson
2023-05-11 13:51 ` Tom Rini
2023-05-11 13:51 ` Tom Rini
2023-05-05 10:25 ` [RFC PATCH 2/5] lib/lwip: compile-in core files Maxim Uvarov
2023-05-05 10:25 ` [RFC PATCH 3/5] add doc/README.lwip Maxim Uvarov
2023-05-11 13:51 ` Tom Rini
2023-05-05 10:25 ` [RFC PATCH 4/5] add doc/README.lwip.size Maxim Uvarov
2023-05-11 13:51 ` Tom Rini
2023-05-05 10:25 ` [RFC PATCH 5/5] lwip: implement wget command from http_client.c example Maxim Uvarov
2023-05-05 10:27 ` [RFC PATCH 0/5] LWIP stack integration Ilias Apalodimas
2023-05-08 21:23 ` Simon Glass
2023-05-11 13:28 ` Maxim Uvarov
2023-05-11 13:52 ` Tom Rini
2023-05-15 15:25 ` Maxim Uvarov
2023-05-15 15:39 ` Tom Rini
2023-05-19 13:17 ` Ilias Apalodimas
2023-05-19 13:52 ` Tom Rini
2023-05-22 9:01 ` Maxim Uvarov
2023-05-22 13:33 ` Ilias Apalodimas
2023-05-22 14:20 ` Tom Rini
2023-05-22 16:40 ` Maxim Uvarov
2023-05-22 21:23 ` Tom Rini
2023-05-24 14:05 ` Maxim Uvarov
2023-05-24 20:18 ` [lwip-devel] " Simon Goldschmidt
2023-06-06 14:33 ` Maxim Uvarov
2023-06-07 9:46 ` Ilias Apalodimas
2023-06-07 12:01 ` Maxim Uvarov
2023-06-11 8:24 ` Simon Glass
2023-06-11 18:34 ` Tom Rini [this message]
2023-06-07 20:07 ` Tom Rini
2023-06-08 10:14 ` Maxim Uvarov
2023-06-08 17:52 ` Ilias Apalodimas
2023-06-09 7:37 ` Peter Robinson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20230611183452.GC835503@bill-the-cat \
--to=trini@konsulko.com \
--cc=goldsimon@gmx.de \
--cc=ilias.apalodimas@linaro.org \
--cc=joe.hershberger@ni.com \
--cc=lwip-devel@nongnu.org \
--cc=maxim.uvarov@linaro.org \
--cc=pbrobinson@redhat.com \
--cc=rfried.dev@gmail.com \
--cc=sjg@chromium.org \
--cc=u-boot@lists.denx.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox