From owner-freebsd-net@FreeBSD.ORG Sun Mar 30 10:13:45 2008 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 1F6BA106566B for ; Sun, 30 Mar 2008 10:13:45 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe05.swip.net [212.247.154.129]) by mx1.freebsd.org (Postfix) with ESMTP id B51648FC13 for ; Sun, 30 Mar 2008 10:13:44 +0000 (UTC) (envelope-from hselasky@c2i.net) X-Cloudmark-Score: 0.000000 [] Received: from [62.113.132.89] (account mc467741@c2i.net [62.113.132.89] verified) by mailfe05.swip.net (CommuniGate Pro SMTP 5.1.13) with ESMTPA id 773504940; Sun, 30 Mar 2008 11:13:33 +0200 From: Hans Petter Selasky To: freebsd-hackers@freebsd.org, FreeBSD Net Date: Sun, 30 Mar 2008 11:14:42 +0200 User-Agent: KMail/1.9.7 References: <47EF4F18.502@FreeBSD.org> In-Reply-To: <47EF4F18.502@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200803301114.43336.hselasky@c2i.net> Cc: Alexander Motin Subject: Re: Multiple netgraph threads 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: Sun, 30 Mar 2008 10:13:45 -0000 Hi, Have you thought about nodes that lock the same mutex must be run on the same thread else for example one thread will run while another will just waits for a mutex ? You can achieve this by grouping nodes into a tree, and the node at the top of the tree decides on which thread the nodes in the tree should be run. How does your patch handle this ? Also see recent discussion about multithreaded callouts on "freebsd-arch@freebsd.org". Subject "timeout/callout small step forward". --HPS On Sunday 30 March 2008, Alexander Motin wrote: > Hi. > > I have implemented a patch (for the HEAD) making netgraph to use several > own threads for event queues processing instead of using single swinet. > It should significantly improve netgraph SMP scalability on complicated > workloads that require queueing by implementation (PPTP/L2TP) or stack > size limitations. It works perfectly on my UP system, showing results > close to original or even a bit better. I have no real SMP test server > to measure real scalability, but test on HTT CPU works fine, utilizing > both virtual cores at the predictable level. > > Reviews and feedbacks are welcome. > > URL: http://people.freebsd.org/~mav/netgraph.threads.patch