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.