From owner-freebsd-stable@freebsd.org Mon Sep 19 21:28:59 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id CE48CBE1E76 for ; Mon, 19 Sep 2016 21:28:59 +0000 (UTC) (envelope-from lyndon@orthanc.ca) Received: from orthanc.ca (orthanc.ca [IPv6:2607:f2f8:abf8::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "orthanc.ca", Issuer "Let's Encrypt Authority X1" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id B982610BB for ; Mon, 19 Sep 2016 21:28:59 +0000 (UTC) (envelope-from lyndon@orthanc.ca) Received: from localhost (localhost [IPv6:::1]) by orthanc.ca (8.15.2/8.15.2) with ESMTPS id u8JLSuOU055613 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 19 Sep 2016 14:28:56 -0700 (PDT) (envelope-from lyndon@orthanc.ca) Date: Mon, 19 Sep 2016 14:28:56 -0700 (PDT) From: Lyndon Nerenberg To: "Dean E. Weimer" cc: FreeBSD Stable Subject: Re: LAGG and Jumbo Frames In-Reply-To: <04c9065ee4a780c6f8986d1b204c4198@dweimer.net> Message-ID: References: <48926c6013f938af832c17e4ad10b232@dweimer.net> <04c9065ee4a780c6f8986d1b204c4198@dweimer.net> User-Agent: Alpine 2.20 (BSF 67 2015-01-07) Organization: The Frobozz Magic Homing Pigeon Company MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed X-Spam-Status: No, score=-1.5 required=5.0 tests=ALL_TRUSTED,BAYES_00, MISSING_DATE autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on orthanc.ca X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Sep 2016 21:28:59 -0000 > Everything on physical Ethernet has support for it Including the LAN > interface of Firewall, and talks to it just fine over a single interface with > Jumbo frames enabled. Well, before you get too carried away, try this: 1) Run a ttcp test between a pair of local hosts using the exiting jumboframes (pick two that you expect high volume traffic between). 2) Run the same test, but with the default MTU. If you don't see a very visible difference in throughput (e.g. >15%), it's not worth the hassle. Just as a datapoint, we're running 10-gigE off some low-end Supermicro boxes with 10.3-RELEASE. Using the default MTU we're getting > 750 MB/s TCP throughput. I can't believe that you won't be able to fully saturate a 1 Gb/s link running the default MTU on anything with more oomph than a dual-core 32-bit Atom. IOW, don't micro-optimize. Life's too short ... --lyndon