From owner-freebsd-current Tue Apr 16 16:40:33 2002 Delivered-To: freebsd-current@freebsd.org Received: from rwcrmhc52.attbi.com (rwcrmhc52.attbi.com [216.148.227.88]) by hub.freebsd.org (Postfix) with ESMTP id C040E37B404; Tue, 16 Apr 2002 16:40:17 -0700 (PDT) Received: from InterJet.elischer.org ([12.232.206.8]) by rwcrmhc52.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020416234017.LBRI1901.rwcrmhc52.attbi.com@InterJet.elischer.org>; Tue, 16 Apr 2002 23:40:17 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id QAA93950; Tue, 16 Apr 2002 16:35:51 -0700 (PDT) Date: Tue, 16 Apr 2002 16:35:51 -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: <3CBC96F2.3032077A@digisle.net> 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 Tue, 16 Apr 2002, Maksim Yevmenkin wrote: > > initially all nodes were WRITERs to "release the stack", but then i > changed my strategy and now i'm serializing data at the edge of graph. > for example both "bt3c" and "h4" nodes will NG_HOOK_FORCE_WRITER on > upstream hook. also i probably should should turn WRITER bit on "ctl" > hook for HCI node since it accepts data. L2CAP node accepts whole > L2CAP packet from upstream hook, so (i think) it should be fine unless > these packets gets re-ordered somehow. protocols that run over L2CAP > may not like it. > > is it possible that SMP Netgraph can re-order data? if so then sockets > node probably should turn WRITER bit on downstream hooks too. it is not likely that data is re-ordered, but remember that data may enter the graph from different edge nodes simultaneously on different processors so that a single node may be processing both incoming and outgoing data at the same time unless the node itself is marked as needing a writer lock. > > > 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.. > > i'm sorry, but i'm not sure what do you mean here. i use such calls > in several places (connect, disconnect, rcvdata) to get to the node > private structure, but (i think) it just a macros that expanded to a > couple pointer accesses. It's not a serious comment. just that you should be aware that one can sometimes simplify code by using the per-hook private information as well. > > > /* 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.. > > you right. i should not destroy item and use NG_FWD_ITEM_HOOK where > required. > Netgraph is not an unchangeable work.. If you have comments on things that may mek it easier to do what you need then please let us (archie & me) know.. > again thank you for your comments, i'm looking forward to hear more :) > thanks, > max > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message