From owner-svn-src-all@freebsd.org Mon Jan 18 23:41:52 2016 Return-Path: Delivered-To: svn-src-all@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 9CB4EA87247; Mon, 18 Jan 2016 23:41:52 +0000 (UTC) (envelope-from marius@alchemy.franken.de) Received: from alchemy.franken.de (alchemy.franken.de [194.94.249.214]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "alchemy.franken.de", Issuer "alchemy.franken.de" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 355141357; Mon, 18 Jan 2016 23:41:51 +0000 (UTC) (envelope-from marius@alchemy.franken.de) Received: from alchemy.franken.de (localhost [127.0.0.1]) by alchemy.franken.de (8.15.2/8.15.2/ALCHEMY.FRANKEN.DE) with ESMTPS id u0INfhTN024882 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 19 Jan 2016 00:41:43 +0100 (CET) (envelope-from marius@alchemy.franken.de) Received: (from marius@localhost) by alchemy.franken.de (8.15.2/8.15.2/Submit) id u0INfh5B024881; Tue, 19 Jan 2016 00:41:43 +0100 (CET) (envelope-from marius) Date: Tue, 19 Jan 2016 00:41:43 +0100 From: Marius Strobl To: Kubilay Kocak Cc: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r293854 - head/sys/dev/e1000 Message-ID: <20160118234142.GM15359@alchemy.franken.de> References: <201601132147.u0DLlR38017711@repo.freebsd.org> <5698473F.8030203@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5698473F.8030203@FreeBSD.org> User-Agent: Mutt/1.5.24 (2015-08-30) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (alchemy.franken.de [0.0.0.0]); Tue, 19 Jan 2016 00:41:43 +0100 (CET) X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jan 2016 23:41:52 -0000 On Fri, Jan 15, 2016 at 12:11:27PM +1100, Kubilay Kocak wrote: > On 14/01/2016 8:47 AM, Marius Strobl wrote: > > Author: marius > > Date: Wed Jan 13 21:47:27 2016 > > New Revision: 293854 > > URL: https://svnweb.freebsd.org/changeset/base/293854 > > > > Log: > > Given that em(4), lem(4) and igb(4) hardware doesn't require the > > alignment guarantees provided by m_defrag(9), use m_collapse(9) > > instead for performance reasons. > > While at it, sanitize the statistics softc members, i. e. retire > > unused ones and add SYSCTL nodes missing for actually used ones. > > > > Differential Revision: https://reviews.freebsd.org/D4717 > > > > Modified: > > head/sys/dev/e1000/if_em.c > > head/sys/dev/e1000/if_em.h > > head/sys/dev/e1000/if_igb.c > > head/sys/dev/e1000/if_igb.h > > head/sys/dev/e1000/if_lem.c > > head/sys/dev/e1000/if_lem.h > > What kind of performance / overhead delta can be expected for this change? > Compared to m_collapse(9), m_defrag(9) is a real CPU hog. However, bus_dmamap_load_mbuf_sg(9) should fail seldom enough with EFBIG that you'll most likely not experience much of a difference in practice. Still, unnecessary use of m_defrag(9) in place of m_collapse(9) should be avoided and at some point in time we actually had managed to get rid of most of these cases. Unfortunately, such code came back in a couple of drivers, mainly in vendor-supplied ones. > Is this worth MFC and/or Relnotes ? The change is worth an MFC but not Relnotes. Marius