From owner-freebsd-net@FreeBSD.ORG Sun Mar 30 09:49:29 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 2E117106566B; Sun, 30 Mar 2008 09:49:29 +0000 (UTC) (envelope-from mav@FreeBSD.org) Received: from cmail.optima.ua (cmail.optima.ua [195.248.191.121]) by mx1.freebsd.org (Postfix) with ESMTP id 73A788FC12; Sun, 30 Mar 2008 09:49:28 +0000 (UTC) (envelope-from mav@FreeBSD.org) X-Spam-Flag: SKIP X-Spam-Yversion: Spamooborona-2.1.0 Received: from [212.86.226.226] (account mav@alkar.net HELO [192.168.3.2]) by cmail.optima.ua (CommuniGate Pro SMTP 5.1.14) with ESMTPA id 99987913; Sun, 30 Mar 2008 12:49:27 +0300 Message-ID: <47EF6226.3090808@FreeBSD.org> Date: Sun, 30 Mar 2008 12:49:26 +0300 From: Alexander Motin User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Hans Petter Selasky References: <47EF4F18.502@FreeBSD.org> <200803301114.43336.hselasky@c2i.net> In-Reply-To: <200803301114.43336.hselasky@c2i.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org, FreeBSD Net 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 09:49:29 -0000 Hans Petter Selasky wrote: > 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 ? Usually different nodes does not share data, keeping them inside node/hook private data, so I don't see problem here. It is possible that two messages will be queued to the same node at same time, but to fulfil serialization requirements each node queue processed only by one thread at a time, so there is no place for congestion. > 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. Netgraph graphs usually not linear and it is from hard to impossible to predict the way execution will go and the locks that may be congested. Including usually big number of nodes and usually small lock time, congestion probability IMHO looks insignificant comparing to additional logic overhead. If some node/hook needs big lock time it may be instead declared as FORCE_WRITER to enqueue congested messages instead of blocking them (such way now implemented all existing ppp compression/encryption nodes). -- Alexander Motin