From owner-freebsd-arch@FreeBSD.ORG Tue Aug 31 23:09:19 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 84D9D16A4CE; Tue, 31 Aug 2004 23:09:19 +0000 (GMT) Received: from mail.vicor-nb.com (bigwoop.vicor-nb.com [208.206.78.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7493A43D31; Tue, 31 Aug 2004 23:09:19 +0000 (GMT) (envelope-from julian@elischer.org) Received: from elischer.org (julian.vicor-nb.com [208.206.78.97]) by mail.vicor-nb.com (Postfix) with ESMTP id 222AE7A3E1; Tue, 31 Aug 2004 16:09:19 -0700 (PDT) Message-ID: <4135051E.2070007@elischer.org> Date: Tue, 31 Aug 2004 16:09:18 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.3.1) Gecko/20030516 X-Accept-Language: en, hu MIME-Version: 1.0 To: Scott Long References: <4134DF35.7070605@freebsd.org> <20040831203929.GB25134@odin.ac.hmc.edu> <4134E4B6.2030409@elischer.org> <4134FCAE.7374599A@freebsd.org> <4134FF74.4010105@freebsd.org> In-Reply-To: <4134FF74.4010105@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: Sam cc: Andre Oppermann cc: freebsd-arch@freebsd.org Subject: Re: option directive and turning on AOE X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Aug 2004 23:09:19 -0000 Scott Long wrote: > Andre Oppermann wrote: > >> > > Having a single common interface is definitely attractive, but there are > performance and locking issues with the Netgraph framework that should > probably be resolved first. both of these issues are in fact not major.. netgraph itself has no locking issuess.. (Netgraph is the framework), but some of teh node types have issues. Specifically, node types that can be caled from outside the netgraph framework, such as nodes that tie netgraph to other subsystems need to be worked on so that control enterring netgraph code from those subsystems gets an appropriate lock. This is not always needed, but every node needs to be examined with this in mind now that we have locking in teh rest of the system more worked out. performace.. well it can be fast. it depends on a lot of issues however.. in particular how many locks get contentions. > > > Scott