From owner-svn-src-head@FreeBSD.ORG Fri Jun 12 00:52:41 2009 Return-Path: Delivered-To: svn-src-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5FAA4106564A; Fri, 12 Jun 2009 00:52:41 +0000 (UTC) (envelope-from kabaev@gmail.com) Received: from mail-qy0-f173.google.com (mail-qy0-f173.google.com [209.85.221.173]) by mx1.freebsd.org (Postfix) with ESMTP id C23998FC15; Fri, 12 Jun 2009 00:52:40 +0000 (UTC) (envelope-from kabaev@gmail.com) Received: by qyk3 with SMTP id 3so2694386qyk.3 for ; Thu, 11 Jun 2009 17:52:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:date:from:to:cc:subject :message-id:in-reply-to:references:x-mailer:mime-version :content-type; bh=rjk9fCnG94ezrqM/DfRzsMuaxw2AV0UA3v+PwdooyFg=; b=XzSgFB2wEEWF2pF+j4EU7/NTrj/rW1K8nV93gnOLdEnvtGSQqcOAMCmAtf9ixxXWO8 QKiQq+ZPhx8Ln4jr7bJGMr5JXPeMC+dvH1Qd0l2L3j6coOluWC7HX+DP1c8/ujbSKjyV I/sDnw+GWm8izfNrE9BIaprrv87lVs188LLAM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:in-reply-to:references:x-mailer :mime-version:content-type; b=KyNorEoTuF94WacQuvH/6Ypu0Bq2vnQt9fQlmJBsGiIMyWZdSFS8uLkPrBhGj7AbmZ eykgKHthI3Lugf5f/0NFXPNoDnDRaNUMcs85gtiYhBS1pYdvaH7QTd/c2l4zpK9t5LJi sjofmZMu0+/CXynoI8fwSwpAxMKYaG59M5lP4= Received: by 10.224.19.131 with SMTP id a3mr3827119qab.23.1244766485047; Thu, 11 Jun 2009 17:28:05 -0700 (PDT) Received: from kan.dnsalias.net (c-98-217-224-113.hsd1.ma.comcast.net [98.217.224.113]) by mx.google.com with ESMTPS id 7sm772541qwf.29.2009.06.11.17.28.03 (version=SSLv3 cipher=RC4-MD5); Thu, 11 Jun 2009 17:28:04 -0700 (PDT) Date: Thu, 11 Jun 2009 20:27:57 -0400 From: Alexander Kabaev To: Julian Elischer Message-ID: <20090611202757.7cb0dad5@kan.dnsalias.net> In-Reply-To: <4A3168A0.2090308@elischer.org> References: <200906111650.n5BGonnn053446@svn.freebsd.org> <20090611190140.GE2642@garage.freebsd.pl> <200906112123.02105.zec@freebsd.org> <4A3168A0.2090308@elischer.org> X-Mailer: Claws Mail 3.7.1 (GTK+ 2.16.2; i386-portbld-freebsd8.0) Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/tZE2c3nejT_urZzkoxJV3Jj"; protocol="application/pgp-signature" Cc: svn-src-head@freebsd.org, Pawel Jakub Dawidek , svn-src-all@freebsd.org, src-committers@freebsd.org, Marko Zec Subject: Re: svn commit: r194012 - in head: . sys/netgraph sys/sys X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jun 2009 00:52:41 -0000 --Sig_/tZE2c3nejT_urZzkoxJV3Jj Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Thu, 11 Jun 2009 13:27:12 -0700 Julian Elischer wrote: > Marko Zec wrote: > > On Thursday 11 June 2009 21:01:40 Pawel Jakub Dawidek wrote: > >> On Thu, Jun 11, 2009 at 04:50:49PM +0000, Marko Zec wrote: > >>> Author: zec > >>> Date: Thu Jun 11 16:50:49 2009 > >>> New Revision: 194012 > >>> URL: http://svn.freebsd.org/changeset/base/194012 > >>> > >>> Log: > >>> Introduce a mechanism for detecting calls from outbound path of > >>> the network stack when reentering the inbound path from netgraph, > >>> and force queueing of mbufs at the outbound netgraph node. > >>> > >>> The mechanism relies on two components. First, in netgraph > >>> nodes where outbound path of the network stack calls into > >>> netgraph, the current thread has to be appropriately marked using > >>> the new NG_OUTBOUND_THREAD_REF() macro before proceeding to call > >>> further into the netgraph topology, and unmarked using the > >>> NG_OUTBOUND_THREAD_UNREF() macro before returning to the caller. > >>> Second, netgraph nodes which can potentially reenter the network > >>> stack in the inbound path have to mark their inbound hooks using > >>> NG_HOOK_SET_TO_INBOUND() macro. The netgraph framework will > >>> then detect when there is a danger of a call graph looping back > >>> from outbound to inbound path via netgraph, and defer handing off > >>> the mbufs to the "inbound" node to a worker thread with a clean > >>> stack. > >>> > >>> In this first pass only the most obvious netgraph nodes have > >>> been updated to ensure no outbound to inbound calls can occur. > >>> Nodes such as ng_ipfw, ng_gif etc. should be further examined > >>> whether a potential for outbound to inbound call looping exists. > >>> > >>> This commit changes the layout of struct thread, but due to > >>> __FreeBSD_version number shortage a version bump has been > >>> omitted at this time, nevertheless kernel and modules have to be > >>> rebuilt. > >> Are you sure Marko that you can't use sys/sys/osd.h instead of > >> adding yet another field to the thread structure? Netgraph is > >> optional component and optional components could take advantage of > >> allocating stuff they need dynamically. The OSD (Object-Specific > >> Data) KPI is designed for use by optional components - you can add > >> your data to a thread, you can get it when you want and OSD will > >> call your callback when thread dies, so you can clean up. > >> > >> Maybe you can't, but it's worth checking. > >=20 > > Hmm how much locking overhead do osd_set() / osd_get() methods > > introduce? We have to bump the refcount on each entry to netgraph, > > and then check it potentially on each hop to next ng node, and > > finally drop the refcount when done with the function call into > > netgraph. Accessing td_ng_outbound directly via curthread is as > > cheap as it gets performancewise as it requires no locking > > whatsoever... >=20 > I would add that I suspect that we may end up using it in other > places as well outside of netgraph. >=20 When that happens then per-thread field can be revisited again. Blowing the side of major kernel structure for the sake of subsystem is unused by 90%+ percent of users is little too drastic IMHO. I do second Pawel's opinion that you should look at osd for the time being. After all it was invented for just this reason. --=20 Alexander Kabaev --Sig_/tZE2c3nejT_urZzkoxJV3Jj Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (FreeBSD) iD8DBQFKMaESQ6z1jMm+XZYRAmoaAJ0aN9TcVyUrA0YwIdca3HrZ7FLcjACgy/PQ qlhpfc1PpiFDR60KfrYlPSU= =qWGc -----END PGP SIGNATURE----- --Sig_/tZE2c3nejT_urZzkoxJV3Jj--