From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1SPy3S-0008US-70 for mharc-grub-devel@gnu.org; Thu, 03 May 2012 11:34:54 -0400 Received: from eggs.gnu.org ([208.118.235.92]:34476) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SPy3K-0008LA-KL for grub-devel@gnu.org; Thu, 03 May 2012 11:34:52 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SPy3F-0003YK-PX for grub-devel@gnu.org; Thu, 03 May 2012 11:34:46 -0400 Received: from mail-we0-f169.google.com ([74.125.82.169]:45555) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SPy3F-0003Wj-GD for grub-devel@gnu.org; Thu, 03 May 2012 11:34:41 -0400 Received: by werb14 with SMTP id b14so503542wer.0 for ; Thu, 03 May 2012 08:34:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:x-enigmail-version:content-type; bh=OVUKU6a6L7TbeXUfPBorzBHSRRx6GUpzE1LsbgGAXec=; b=E1sGZqwdCMILW0Sqygk9cVe6xD1Qil0PSoGFoNtGmuPQk3sSMOqS+0ODjQ9TE2Ve0B QQEwxqA3FVY/nzGY113lIvnnHli1ODl5DmkKNeDfDgGqbPOCsEGCc1arDBPZp+3t/w7V YLvPx55Ocits1bmy75m/5RI4bE+wnJYfctZiKYhZyY4555TYeR8LrmNUAYfneFSpFZG7 k3kSehlauesuV6xBpIHfotrfDpzYBRVK6g6PbQWGIP8OCMD+P2pHW9WUmzGR7fsaIBb1 mjlDPGruzn5L67l1ZDU6ZbKZSkeJprwW2Lm3XlTKz5gYi6PmP9NS84Ik54GpPJ8I77v+ XBgA== Received: by 10.180.105.69 with SMTP id gk5mr5061450wib.3.1336059278019; Thu, 03 May 2012 08:34:38 -0700 (PDT) Received: from debian.x201.phnet (public-docking-hg-4-235.ethz.ch. [129.132.244.235]) by mx.google.com with ESMTPS id ea6sm439160wib.5.2012.05.03.08.34.35 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 03 May 2012 08:34:36 -0700 (PDT) Message-ID: <4FA2A589.9090407@gmail.com> Date: Thu, 03 May 2012 17:34:33 +0200 From: =?UTF-8?B?VmxhZGltaXIgJ8+GLWNvZGVyL3BoY29kZXInIFNlcmJpbmVua28=?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.3) Gecko/20120329 Icedove/10.0.3 MIME-Version: 1.0 To: grub-devel@gnu.org Subject: Re: [PATCH] bug fix for efi network References: <4F9D6F43.1010607@gmail.com> In-Reply-To: X-Enigmail-Version: 1.4.1 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="------------enig344BBA243E07450EBB5A8828" X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 74.125.82.169 X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: The development of GNU GRUB List-Id: The development of GNU GRUB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 May 2012 15:34:52 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig344BBA243E07450EBB5A8828 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 29.04.2012 20:19, Bean wrote: > 2012/4/30 Vladimir '=CF=86-coder/phcoder' Serbinenko : >> 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 fragmentati= on >> 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 packet= s. >> k=3D1 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. > --=20 Regards Vladimir '=CF=86-coder/phcoder' Serbinenko --------------enig344BBA243E07450EBB5A8828 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iF4EAREKAAYFAk+ipYkACgkQNak7dOguQgmTTwD/UjLxyLEWWEDFW/t/ikVFDIMb /xPGayb4m2feHiffDWcBAL2nYkzdIMwwmcBf0bKksYWUXlvUYf5bE1bVW7fLKhuV =ZhJY -----END PGP SIGNATURE----- --------------enig344BBA243E07450EBB5A8828--