[syslinux] Problem with 90MB Initrd

[Patrick Masotta]

>>>>>

>>>>
>
>  > BTW if you take a minute and read the first report
>  > https://communities.vmware.com/message/2536774
>  > You'll realize that VMWare TFTP "surprisingly" does not present slow TFTP transfers
>  > when they are driven by MS "bootmgfw.efi"; instead the problem is only shown when
>  > transfers are driven by syslinux.efi; At the moment, despite probably VMware not handling
>  > the net driver "polling" correctly, I started to wonder if "we" are really handling the EFI Event
>  > engine correctly when performing TFTP transfers within syslinux.efi
>  >
>
>  It might be a difference
>  between using the TFTP and using the UDP
>  interfaces, or somesuch.
>
>      -hpa
>  <<<
>
> Sure "bootmgfw.efi" is doing something better than we do about TFTP transfers.
> They:
> 1) do not rely on Service Binding Protocols then old EFI firmware PCs do not complain.
> 2) I think they do better when handling EFI Events and Timers.
>
> The key to see how they do what they do is this bootmgfw.efi function:
> TftppGetImageRegular
> but the task is time consuming; efi environment functions are only referenced by an index
> on a pointer table then knowing what functions they are really calling is not very easy
> to see.
My current inclination is that there's a bug in Syslinux's TFTP+UDP
implementation.  If it's in the TFTP implementation, lpxelinux.0
should also exhibit issues with larger files (which I seem to recall
but can't be certain at the moment).
 
-Gene
<<<<<

It seems today most of the EFI FW producers test their stuff 

mainly against MS bootmgfw.efi. If everything works well with it 

then no deeper testing is performed.
If this is really the case it would be very difficult to determine if the
problem is located in syslinux.efi or in some not compliant firmware
(i.e. HP, VMware, etc). 
For all of the above I think we should really understand what bootmgfw.efi 

does and avoid (when possible) other experiments in the EFI arena.


In the past few days I have been comparing bootmgfw.efi and syslinux.efi
TFTP strategies and these are differences I've found so far:

1) bootmgfw.efi uses the UDP capabilities of EFI_PXE_BASE_CODE_PROTOCOL (PXEbc
is layered on top of an EFI_MANAGED_NETWORK_PROTOCOL protocol in order to 

perform packet level transactions)

_UdpFunctionTable
    _UdpOpen()
    _UdpClose()
    _UdpRead()
    _UdpWrite()
    _UdpGetInformation()
    _UdpSetInformation()

on the other hand syslinux.efi uses EFI_UDP4_SERVICE_BINDING_PROTOCOL/EFI_UDP4_PROTOCOL instead.

About PXEbc Peter has recently said:
> The problem with the pxebc is that it only supports one concurrent TFTP
> connection, and Syslinux expects to be able to keep multiple files open
> at the same time.
> http://www.syslinux.org/archives/2015-August/024025.html

I wonder why should syslinux.efi ever need to TFTP transfer more than one file simultaneously?


2) when receiving TFTP blocks bootmgfw.efi uses asynchronous "timers" per block without "any" 

callback function and the timeout seems to be constant; always 2 seconds.

On the other hand syslinux.efi uses a combination of synchronous timers (TimerPeriodic)
with callback function to calculate "jiffies" which is used to determine the increasing 

receive timeout (based on a table). 

The reception of every block also creates an event triggered by EFI_EVENT_NOTIFY which calls 

a callback function (udp4_cb()) just to change a status (cb_status). Next we keep polling the 

cb_status variable while calling EFI_UDP4_PROTOCOL.Poll()to speed things up.


So far I have been focusing my analysis on the EFI/UDP side of things because Wireshark 

traffic captures shown a pretty constant heavy delay (under VMware) between the reception of a data 

block and the corresponding ACK hitting the wire; that doesn't look like a problem on the TFTP algorithm.

I think we should probably reconsider the EFI/UDP approach of syslinux.efi. 

What do you guys think?


Best,
Patrick