Re: [PATCH v4 00/14] Introduce the lwIP network stack

[Tom Rini <trini@konsulko.com>]

[-- Attachment #1: Type: text/plain, Size: 4251 bytes --]

On Wed, Jun 19, 2024 at 04:47:08PM +0200, Jerome Forissier wrote:
> 
> 
> On 6/19/24 09:24, Ilias Apalodimas wrote:
> > Hi Tom
> > 
> > On Tue, 18 Jun 2024 at 23:21, Tom Rini <trini@konsulko.com> wrote:
> >>
> >> On Mon, Jun 17, 2024 at 05:32:52PM +0200, Jerome Forissier wrote:
> >>
> >>> This is a rework of a patch series by Maxim Uvarov: "net/lwip: add lwip
> >>> library for the network stack" [1]. The goal is to introduce the lwIP TCP/IP
> >>> stack [2] [3] as an alternative to the current implementation in net/,
> >>> selectable with Kconfig, and ultimately keep only lwIP if possible. Some
> >>> reasons for doing so are:
> >>> - Make the support of HTTPS in the wget command easier. Javier T. (CC'd)
> >>> has some additional lwIP and Mbed TLS patches to do so. With that it
> >>> becomes possible to fetch and launch a distro installer such as Debian
> >>> etc. using a secure, authenticated connection directly from the U-Boot
> >>> shell. Several use cases:
> >>>   * Authentication: prevent MITM attack (third party replacing the
> >>> binary with a different one)
> >>>   * Confidentiality: prevent third parties from grabbing a copy of the
> >>> image as it is being downloaded
> >>>   * Allow connection to servers that do not support plain HTTP anymore
> >>> (this is becoming more and more common on the Internet these days)
> >>> - Possibly benefit from additional features implemented in lwIP
> >>> - Less code to maintain in U-Boot
> >>
> >> So, on a Pi 3 (rpi_3_defconfig) I see this now (and it passes normally):
> >> ========================================== FAILURES ===========================================
> >> ___________________________________ test_efi_helloworld_net ___________________________________
> >> test/py/tests/test_efi_loader.py:163: in test_efi_helloworld_net
> >>     assert expected_text in output
> >> E   AssertionError: assert 'Hello, world' in 'No UEFI binary known at 200000'
> >> ------------------------------------ Captured stdout call -------------------------------------
> >> U-Boot> tftpboot 200000 EFI/arm64/helloworld.efi
> >> Using smsc95xx_eth device
> >> TFTP from server 192.168.1.10; our IP address is 192.168.1.100
> >> Filename 'EFI/arm64/helloworld.efi'.
> >> Load address: 0x200000
> >> Loading:
> >> Bytes transferred = 4528 (11b0 hex)
> >> U-Boot> U-Boot> crc32 200000 $filesize
> >> CRC32 for 00200000 ... 002011af ==> 2b466005
> >> U-Boot> U-Boot> bootefi 200000
> >> No UEFI binary known at 200000
> >> U-Boot>
> >> =================================== short test summary info ===================================
> >> If I disable that test, it moves on to failing the same exact way for
> >> grub. If I disable the grub test too. After that, oh, a bunch of other
> >> tests get skipped because CMD_NET and similar aren't enabled now, and
> >> the tests are wrong. I'll post that as another patch by itself. After
> >> correcting for that, we're seemingly noticeably slower as I need to
> >> increase the timeout for tftp'ing my 83MiB FIT image I use for kernel
> >> testing. We no longer have the estimated speed message, so I can't as
> >> easily say how much slower it is. After increasing the timeout, the
> >> kernel boot test does work.
> >>
> >> I can note that normally it takes ~18ms to get a dhcp reply, but with
> >> lwIP it's now 132ms, and previously the kernel loaded at 2.7MiB/s
> >> (which, not great) but if that has a similar level of slowdown, could
> >> well explain it.
> >>
> > 
> > Thanks for taking the time. We'll run the pytests before v5. That
> > being said, my wget tests were faster with lwIP last time I checked.
> 
> The reason for the slower TFTP is the block size. lwIP supports only the
> default (512 bytes), while the legacy stack supports the 'blksize' option
> and sets CONFIG_TFTP_BLOCKSIZE=1468 by default.

Ouch. Can we ask if upstream is agreeable to making that configurable
some way, and then we utilize that? I'm not looking forward to lots of
performance hit reports.

But please note that my dhcp request/reply is also taking 10x as long,
and in v3 it wasn't working at all? I feel like there's possibly another
issue lurking here.

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]