From owner-freebsd-current Mon Apr 15 18:20:18 2002 Delivered-To: freebsd-current@freebsd.org Received: from rwcrmhc53.attbi.com (rwcrmhc53.attbi.com [204.127.198.39]) by hub.freebsd.org (Postfix) with ESMTP id 27A9837B41C; Mon, 15 Apr 2002 18:20:09 -0700 (PDT) Received: from InterJet.elischer.org ([12.232.206.8]) by rwcrmhc53.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020416012008.QIKU1083.rwcrmhc53.attbi.com@InterJet.elischer.org>; Tue, 16 Apr 2002 01:20:08 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id SAA89304; Mon, 15 Apr 2002 18:04:38 -0700 (PDT) Date: Mon, 15 Apr 2002 18:04:37 -0700 (PDT) From: Julian Elischer To: Maksim Yevmenkin Cc: freebsd-current@freebsd.org, freebsd-net@freebsd.org Subject: Re: Bluetooth stack for FreeBSD In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Mon, 15 Apr 2002, Julian Elischer wrote: > > [out of time for now.. will read more later] > > Julian > ok, read a bit more: you say: 2) Locking/SMP External code now uses ng_send_fn to inject data into Netgraph, so it should be fine as long as Netgraph is SMP safe. Just need to verify it. yes this is correct While Netgraph is not completely SMP safe yet, this is only because there are several nodes that do not do what you do here. By doing it corectly here you have ensured that this will not be one of the nodes that needs to be reworked when this becomes important. (soon). Any node that changes it's internal state with reception of DATA (as opposed to control messages) should ensure that it by doing: NG_NODE_FORCE_WRITER(node); This is because in the default state, multiple data messages may (under SMP) be transitting the node at a time, as they only take out READER locks. If DATA can change some state variable or similar then this becomes unsafe, and they should be serialised. If only SOME data can do this, you have the option to takew reader-locks and only after confirming that a message is a writer, upgrade to a writer lock by 'requeueing' it as such. Alternatively teh sender can mark a packet as 'writer'. --- NG_NODE_PRIVATE(NG_HOOK_NODE(hook)) can be saved if you store information relavant to a hook in it's own private data pointer.. In some nodes I store the same data in NG_HOOK_PRIVATE(hook) as is in NG_NODE_PRIVATE(node), just to save the dereference if it's going to be done per packet. Sometimes there are better things to store there however.. --- /* Detach mbuf, discard item and process data */ NGI_GET_M(item, m); NG_FREE_ITEM(item); If there is any chance that you will need a new 'item' in a function or a child function, then it's worth keeping them around to save teh expense of re-allocating them.. I guess I shuld make a macro NG_FWD_DATA_HOOK() to make this easier to do.. -- > > > > On Mon, 15 Apr 2002, Maksim Yevmenkin wrote: > > > Folks, > > > > [probably should be cc'd to -mobile as well] > > > > An engineering release of Bluetooth stack for -current FreeBSD > > is available for download at > > > > http://www.geocities.com/m_evmenkin/ngbt-fbsd-20020415.tar.gz > > > > i'm interested to hear from people who familiar with FreeBSD > > kernel, Netgraph and/or Bluetooth. all your questions/comments/ > > suggestions are accepted and greatly appreciated. this is my > > first Netgraph stack, so please don't me hard :) > > > > thanks, > > max > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > with "unsubscribe freebsd-current" in the body of the message > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-current" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message