On 6/19/24 17:07, Tom Rini wrote:
> 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 <tr...@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.
I tried a quick & dirty hack to hardcode the blksize option in the lwIP
stack and I can confirm I get the same speed as with the legacy
implementation or even slightly better (legacy: 822 KB/s, hacked lwIP:
843 KB/s, upstream lwIP: 343 KB/s). That's on QEMU with py3tftp running on
my laptop as a TFTP server. I would probably get better results with a
good TFTP server and real hardware (RPi...) but at least this shows lwIP
can be on par with the U-Boot stack.
I can consider writing a better patch for lwIP and submitting it upstream.
> 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.
This I need to investigate more on my RPi. I'll keep you posted. Thanks
again for testing.
--
Jerome
