public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
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 --]

  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