From owner-freebsd-net@FreeBSD.ORG Sat Jul 12 12:17:54 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2F4A226B for ; Sat, 12 Jul 2014 12:17:54 +0000 (UTC) Received: from mail-vc0-x236.google.com (mail-vc0-x236.google.com [IPv6:2607:f8b0:400c:c03::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id DE53E2D84 for ; Sat, 12 Jul 2014 12:17:53 +0000 (UTC) Received: by mail-vc0-f182.google.com with SMTP id hq11so4105469vcb.41 for ; Sat, 12 Jul 2014 05:17:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=JP/LHdf05dKFIpOQt7TTEHxurjC/kVk9fdNTia5EmFk=; b=FzwzhZeBDH3JaF2Oi8R9WH5u5VzfpikektpqqO/SXyjNRogC3n95xx2NVGqmkHKXfA jcw3fdnddO2qmK6CwlIY6xZpzWypLtHIHSlxBNFKgbS4DJXluKmxNHgnD28X8bi6g6Ww TLk8WnU8nKVJ/CaZOgpuwSTlWVTNPoEj+P6hGwjG0OPF84eC2vMnf1lBjCFxMCgN1L6F 2qyUYDc2gw1lRYGPiZmc3MW5xvFcjarya7LBITOsjTDA+YsgahMNzJwSAkbz1cTH0M2M rxpv/ZEr2uqVi/yQIHY+/VGKigBAe1QLpWK0VoFPM5oGUSesiwMHYpo2kH5wBgs1TLJs ObNg== X-Received: by 10.58.8.12 with SMTP id n12mr50824vea.28.1405167472840; Sat, 12 Jul 2014 05:17:52 -0700 (PDT) MIME-Version: 1.0 Sender: cochard@gmail.com Received: by 10.58.228.38 with HTTP; Sat, 12 Jul 2014 05:17:32 -0700 (PDT) In-Reply-To: <01AABF44-4801-45B5-9509-1CA7BAA3CB30@lists.zabbadoz.net> References: <53C01EB5.6090701@gmail.com> <01AABF44-4801-45B5-9509-1CA7BAA3CB30@lists.zabbadoz.net> From: =?ISO-8859-1?Q?Olivier_Cochard=2DLabb=E9?= Date: Sat, 12 Jul 2014 14:17:32 +0200 X-Google-Sender-Auth: u3c-BfqqZZqcD-e9kGqPkeeczu8 Message-ID: Subject: Re: tuning routing using cxgbe and T580-CR cards? To: "Bjoern A. Zeeb" Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.18 Cc: FreeBSD Net , Navdeep Parhar , John Jasem X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Jul 2014 12:17:54 -0000 On Fri, Jul 11, 2014 at 8:03 PM, Bjoern A. Zeeb < bzeeb-lists@lists.zabbadoz.net> wrote: > On 11 Jul 2014, at 17:28 , John Jasem wrote: > > > c) the defaults for the cxgbe driver appear to be 8 rx queues, and N tx > > queues, with N being the number of CPUs detected. For a system running > > multiple cards, routing or firewalling, does this make sense, or would > > balancing tx and rx be more ideal? And would reducing queues per card > > based on NUMBER-CPUS and NUM-CHELSIO-PORTS make sense at all? > > ... > > g) Are there other settings I should be looking at, that may squeeze out > > a few more packets? > > If you are primarily forwarding packets (you say "routing" multiple times) > the first thing you should do is turn off LRO and TSO on all ports. > Hi Bjoern, I was not aware of disabling LRO+TSO for forwarding packet. If I read correctly the wikipedia page of LRO[1]: Disabling LRO is not a concern of performance but only of not breaking the end-to-end principle, right ? But regarding TSO[2]: It should improve performance only between the TCP and IP layer. But paquet forwarded didn't have to cross TCP<->IP layer, then disabling TSO should not impact performance, right ? I've tried to benchs the differences on my lab: - Hardware: quad cores (Intel Xeon L5630 2.13GHz, hyper-threading disabled) with 2 ports Intel 10-Gigabit X540-AT2 - Multi-flows (different UDP ports) of small packet (60B) at about 10Mpps (pkt-gen -f tx -i ix0 -n 1000000000 -l 60 -d 9.3.3.1:2000-9.3.3.1:4000 -D a0:36:9f:1e:28:14 -s 8.3.3.1 -w 4) - Result collected on the receiver side in Paquet-Per-Second unit. ministat -w 74 tso.lro.enabled tso.lro.disabled x tso.lro.enabled + tso.lro.disabled +--------------------------------------------------------------------------+ | + + x+ * x+ x x| ||____________M_|_A________________|________A_M_________________________| | +--------------------------------------------------------------------------+ N Min Max Median Avg Stddev x 5 1724046 1860817 1798145 1793343 61865.164 + 5 1702496 1798998 1725396 1734863.2 38178.905 No difference proven at 95.0% confidence => There is not difference: Then I can disable LRO for respecting the end-to-end principle. But why disabling TSO ? Regards, Olivier [1] http://en.wikipedia.org/wiki/Large_receive_offload [2] http://en.wikipedia.org/wiki/Large_segment_offload