Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 30 Mar 2008 12:49:26 +0300
From:      Alexander Motin <mav@FreeBSD.org>
To:        Hans Petter Selasky <hselasky@c2i.net>
Cc:        freebsd-hackers@freebsd.org, FreeBSD Net <freebsd-net@freebsd.org>
Subject:   Re: Multiple netgraph threads
Message-ID:  <47EF6226.3090808@FreeBSD.org>
In-Reply-To: <200803301114.43336.hselasky@c2i.net>
References:  <47EF4F18.502@FreeBSD.org> <200803301114.43336.hselasky@c2i.net>

next in thread | previous in thread | raw e-mail | index | archive | help
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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?47EF6226.3090808>