grub-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] bug fix for efi network


From: Vladimir 'φ-coder/phcoder' Serbinenko
Subject: Re: [PATCH] bug fix for efi network
Date: Thu, 03 May 2012 17:34:33 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.3) Gecko/20120329 Icedove/10.0.3

On 29.04.2012 20:19, Bean wrote:
> 2012/4/30 Vladimir 'φ-coder/phcoder' Serbinenko <address@hidden>:
>> On 29.04.2012 10:22, Bean wrote:
>>> Hi,
>>>
>>> This patch fix a few bugs in efinet.
>>>
>>> It also change the tftp block size from 1024 to 8192, which would
>>> result in HUGE speed difference. In my previous testing, the larger
>>> the block size, the faster the speed. It can reach up to 60-70MB/s in
>>> 1Gb ethernet when block size is about 60K, therefore it would be a
>>> good idea to allow user to configure this parameter. The native tftp
>>> service in UEFI use a default block size of 8192.
>> 8192 is bigger than the MTU on most cards so it results in fragmentation
>> or it emits jumbo packets. It's unclear how both network and server
>> would react to this.
>> Moreover the optimal packet size is in any case:
>> k * (mtu - ip_header_size - udp_header_size - tftp_header_size)
>> where k is some number. Only these number result in fully sized packets.
>> k=1 result in best available option for non-fragmented packets. k > 1
>> can create some preload by abusing fragmentation.
>> Note that some servers do preload by other means and k > 1 with such
>> servers would result in slowdown.
> Hi,
>
> I believe server would split the packets into multiple fragment, each
> within mtu to pass through network, and client assemble them to get
> the original packet. Large block would reduce the number of
> handshakes, and since nic has buffer to cache multiple packets, it
> allows network driver and nic card to work in parallel and thus hide
> some of the network traffic.
But the fragmentation/defragmentation is also something that routers do.
While I'm pretty sure none of them crashes on such packets since the
ping of death, some of them may mishandle such packets or reject them as
an "attack attempt". While this is an interesting possibility to try
out, we need more data as to its functioning in real-world scenarios. We
would also need a way to reestablish connection with a small block if we
notice that the packets aren't comming through or are corrupted.
> Perhaps users with real UEFI implementation can try out different
> block size setting and reports the result.
>


-- 
Regards
Vladimir 'φ-coder/phcoder' Serbinenko


Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]