From owner-freebsd-fs@FreeBSD.ORG Tue Apr 1 00:41:45 2014 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id F39D2EF4; Tue, 1 Apr 2014 00:41:44 +0000 (UTC) Received: from esa-jnhn.mail.uoguelph.ca (esa-jnhn.mail.uoguelph.ca [131.104.91.44]) by mx1.freebsd.org (Postfix) with ESMTP id 7FC1BA82; Tue, 1 Apr 2014 00:41:44 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArkEAPYJOlODaFve/2dsb2JhbABZhBiDCr51gR6BN3SCJQEBAQMBI1YFFg4EBgICDRkCIygOBhOHZQMJCK58mwoNh0sXgSmLOoFoATMHgm+BSQSWYY5YhUqDTCGBbg X-IronPort-AV: E=Sophos;i="4.97,769,1389762000"; d="scan'208";a="110701900" Received: from muskoka.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.222]) by esa-jnhn.mail.uoguelph.ca with ESMTP; 31 Mar 2014 20:41:43 -0400 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id 0BA6DB3F17; Mon, 31 Mar 2014 20:41:43 -0400 (EDT) Date: Mon, 31 Mar 2014 20:41:43 -0400 (EDT) From: Rick Macklem To: Jordan Hubbard Message-ID: <1519461744.3785300.1396312903037.JavaMail.root@uoguelph.ca> In-Reply-To: <5599C60E-7735-4596-B6C5-2EE428D9B248@mail.turbofuzz.com> Subject: Re: RFC: How to fix the NFS/iSCSI vs TSO problem MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Originating-IP: [172.17.91.203] X-Mailer: Zimbra 7.2.1_GA_2790 (ZimbraWebClient - FF3.0 (Win)/7.2.1_GA_2790) Cc: FreeBSD Filesystems , Alexander Motin , Garrett Wollman X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Apr 2014 00:41:45 -0000 Jordan Hubbard wrote: >=20 > On Mar 31, 2014, at 8:53 AM, Marcelo Araujo > wrote: >=20 > > I understand your concern about add more one sysctl, however maybe > > we can > > do something like ZFS does, if it detect the system is AMD and have > > more > > than X of RAM it enables some options by default, or a kind of > > warning can > > be displayed show the new sysctl option. > >=20 > > Of, course other people opinion will be very welcome. >=20 > Why not simply enable (conditionally compile) it in only for the x64 > architecture? If you=E2=80=99re on a 64 bit Intel architecture machine, > chances are pretty good you=E2=80=99re also running hardware of reasonabl= e > recent vintage and aren=E2=80=99t significantly HW constrained. >=20 I'm actually typing this on a single core amd64 with 2Gbytes of RAM, so I think enabling it only for both 64bits and at least some # of Gbytes of RAM would be better. (I agree that most amd64s will be relatively big machines, but not all;-) My biggest problem is that I have no way of testing this on a fairly big amd64 server at this time and I'd be a lot more comfortable committing a patch that has been tested this way. (I realize that Marcelo has been running it for his benchmarks and that's a good start, but it isn't the same as a heavily loaded server.) I notice that Alexander is on the cc list and I've added Garrett, since those are the two guys that have been doing a bunch of server testing (and my thanks go to them for this). Maybe they will have a chance to test this patch on a heavily loaded server? Since I do want to test/debug the if_hw_tsomaxseg patch I have, I plan on inquiring to see if I can use something like the netperf cluster for this testing (in a couple of weeks when I get home). rick > I think it=E2=80=99s also fair to say that if you=E2=80=99re providing NF= S or iSCSI > services on an i386 with 512M of memory or a similarly endowed ARM > or PPC system, performance is not your first and primary concern. > You=E2=80=99re simply happy that it works at all. ;-) >=20 > - Jordan >=20 >=20