From owner-freebsd-net@FreeBSD.ORG Thu Apr 28 22:47:54 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A27D8106564A for ; Thu, 28 Apr 2011 22:47:54 +0000 (UTC) (envelope-from kungfujesus06@gmail.com) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 5E9E48FC0A for ; Thu, 28 Apr 2011 22:47:54 +0000 (UTC) Received: by iwn33 with SMTP id 33so3654971iwn.13 for ; Thu, 28 Apr 2011 15:47:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:date:from:to:cc:subject:message-id:references :mime-version:content-type:content-disposition:in-reply-to :user-agent; bh=NW1A/9P0wOe2G1HZ1NnHUhMtB2hFCOKA5LcsxquQTZU=; b=Qt/sHkkhgIonm0YVjyS555puLjMG4cU46/F5imUShUuvRhq1E9OYw7mcrHW0h8pyZq RZF/udso+WfnsHpIGn2iijwlHTBhiGlSf3AtsPenJnX8JOI4Se8qKUN+CzMRgxzNq6+a 3ZxiyFu/H/96gbXJ0nGEBNFrFAIMEiaKOoU74= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=BrbL91Z+F1mmSV3B8KxEe4KezGhLTjXERzYzrdF2Eic8FlTjTic7VcchDGbrcPb8/P fIjOCpcLN1RPIv//JEKe2aycXtmDTCJlCoWcgISMl5VzVprkSYndJH4cTlCmRmp2gcIK pHcHqb7evtADwx7NPx6eeoxPtmnx7hrII0huc= Received: by 10.42.140.134 with SMTP id k6mr5439832icu.257.1304030873614; Thu, 28 Apr 2011 15:47:53 -0700 (PDT) Received: from freebsdbox.adamsnet ([72.49.234.31]) by mx.google.com with ESMTPS id gy41sm866804ibb.39.2011.04.28.15.47.51 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 28 Apr 2011 15:47:52 -0700 (PDT) Date: Thu, 28 Apr 2011 18:47:49 -0400 From: Adam Stylinski To: Jack Vogel Message-ID: <20110428224749.GA47010@freebsdbox.adamsnet> References: <20110428141339.GD2800@ossumpossum.geop.uc.edu> <20110428144513.GF2800@ossumpossum.geop.uc.edu> <41EE7AB832F24194AC8730544E1C2EB7@multiplay.co.uk> <20110428152141.GA19362@ossumpossum.geop.uc.edu> <11659E32824B4B1E91B6B219BDEF1234@multiplay.co.uk> <20110428160919.GE19362@ossumpossum.geop.uc.edu> <20110428180037.GA1889@zephyr.snd-wireless.uc.edu> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="LQksG6bCIzRHxTLp" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-net@freebsd.org Subject: Re: em0 performance subpar X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Apr 2011 22:47:54 -0000 --LQksG6bCIzRHxTLp Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Apr 28, 2011 at 02:22:29PM -0700, Jack Vogel wrote: > My validation engineer set things up on an 8.2 REL system, testing the > equivalent of > HEAD, and he reports performance is fine. This is without any tweaks from > what's > checked in. >=20 > Increasing the descriptors to 4K is way overkill and might actually cause > problems, > go back to default. >=20 > He has a Linux test client, what are you transmitting to? >=20 > Jack >=20 >=20 > On Thu, Apr 28, 2011 at 11:00 AM, Adam Stylinski wrote: >=20 > > On Thu, Apr 28, 2011 at 09:52:14AM -0700, Jack Vogel wrote: > > > Adam, > > > > > > The TX ring for the legacy driver is small right now compared to em, = try > > > this experiment, > > > edit if_lem.c, search for "lem_txd" and change EM_DEFAULT_TXD to 1024, > > see > > > what > > > that does, then 2048. > > > > > > My real strategy with the legacy code was that it should stable, mean= ing > > not > > > getting > > > a lot of changes... that really hasn't worked out over time. I suppose > > I'll > > > have to try and > > > give it some tweaks and let you try it. The problem with this code is= it > > > technically supports > > > a huge range of old stuff we don't test any more, things I do might c= ause > > > other regressions :( > > > > > > Oh well, let me know if increasing the TX descriptors helps. > > > > > > Jack > > Jack, > > > > Is this the same thing as adjusting these values?: > > > > hw.em.rxd=3D4096 > > hw.em.txd=3D4096 > > > > If so I've maxed this out and it's not helping. I'll give it a shot on= my > > 8-STABLE box as it has a kernel I can play with. > > > > Setting the MTU to 1500 gave lower throughput. > > > > -- > > Adam Stylinski > > PGP Key: http://pohl.ececs.uc.edu/~adam/publickey.pub > > Blog: http://technicallyliving.blogspot.com > > I am transmitting to a linux client (kernel 2.6.38, 9000 byte MTU, PCI-Ex b= ased card). My sysctl's on the Linux client (apart from the default) look = like so: net.ipv4.ip_forward =3D 0 # Enables source route verification net.ipv4.conf.default.rp_filter =3D 1 # Enable reverse path net.ipv4.conf.all.rp_filter =3D 1 net.core.rmem_max =3D 16777216 net.core.wmem_max =3D 16777216 net.ipv4.tcp_rmem =3D 4096 87380 16777216 net.ipv4.tcp_wmem =3D 4096 87380 16777216 net.core.wmem_default =3D 87380 net.core.rmem_default =3D 87380 net.ipv4.tcp_mem =3D 98304 131072 196608 net.ipv4.tcp_no_metrics_save =3D 1 net.ipv4.tcp_window_scaling =3D 1 dev.rtc.max-user-freq =3D 1024 The exact troublesome device (as reported by pciconf):=20 em0@pci0:7:5:0: class=3D0x020000 card=3D0x13768086 chip=3D0x107c8086 rev=3D= 0x05 hdr=3D0x00 vendor =3D 'Intel Corporation' device =3D 'Gigabit Ethernet Controller (Copper) rev 5 (82541PI)' class =3D network subclass =3D ethernet Apart from bus saturation (which I don't suspect is the problem) I'm not su= re what the issue could be. What should I try next? --=20 Adam Stylinski PGP Key: http://pohl.ececs.uc.edu/~adam/publickey.pub Blog: http://technicallyliving.blogspot.com --LQksG6bCIzRHxTLp Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (FreeBSD) iQIcBAEBAgAGBQJNue6UAAoJED6sRHE6TvmnZKwQAK5xSsMFsuIA12imVJx8RLAs bPmk9mMzohYvYSYZb7O7YASEV3tXdt7c+QABy5WiGykit+gvK1zgZ092p2aObvn3 TV7m0nnajawfAr/Dtoxve/hs/VPDEF4ldkmtc14aM0bv1uPAaAKJ7IVovd0fzdG7 UC1DSHOfv2zJ9oEHHcrZtOqm5xfNzJ29nn26GzqyDVLvLY+V0UuzS5EQXS0AzKmw GjGQzsKyU73WGVaYKySM39v6eNNeIY9RRuNlLUpHNpYBEdU7Yl8Nn+BWPV1ERFU3 Syyt6atIQ37G0/AaFpQjMeinO+1Gg3fRQ2xNpzy5nvvKLUs4YN+aaKLDsg9SIczL UcE7m88ErR2xR96Jm4bVl5Q1V+8v/qbSOfwSo0ZGkThbnO0kspRZ7KkZbeepAxIG z3PY4nF5uY0HC3zV4UtmkwDyRDexFns4Y/8yRJmobf+UpxmakgDqNEIhuF59XH0r PbOFXzhF1meX4O7AJ/HG2KZkiyzD8TSgGLZ3XbwUkuFK7mFcmASnVeVOaCG7IagC 3vLpv/vZSYBtM7nl0+UVmYJtv+2eCzPs2ObdZQz6DO/SOJLEIyOOBQmqqp4k0FtZ rU7jXup7kdi0nzbDaY2xZ7/NJaA2Lg81yI5g3UhbyVUoxu2zKpK6WtBBKUxctKWD 3JloE192P62CHYIFf1sQ =LzTp -----END PGP SIGNATURE----- --LQksG6bCIzRHxTLp--