From owner-freebsd-net@FreeBSD.ORG Thu May 20 22:26:54 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EB34C16A4CE for ; Thu, 20 May 2004 22:26:54 -0700 (PDT) Received: from mail.sandvine.com (sandvine.com [199.243.201.138]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6746043D39 for ; Thu, 20 May 2004 22:26:54 -0700 (PDT) (envelope-from ddenissov@sandvine.com) Received: by mail.sandvine.com with Internet Mail Service (5.5.2657.72) id ; Fri, 21 May 2004 01:26:53 -0400 Message-ID: From: Dmitri Denissov To: 'Julian Elischer' , freebsd-net@freebsd.org Date: Fri, 21 May 2004 01:26:52 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Subject: RE: protecting netgraph calls from outside of the network context X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 May 2004 05:26:55 -0000 On Thu, 20 May 2004, Julian Elischer wrote: > > This is kind of a bridge, connected to ng_ether interface nodes. > > Sometimes it queues received packets and later /on a timer > call or a call > > from the user space/ > > it re-injects the packets using ng_send_data. > > > > reinjects it to where? > To the adjacent ng_ether node connected via the lower hook. So the question is how to protect the ng_send_data() call originated from timer or user space context. > > > > > > From: Julian Elischer [mailto:julian@elischer.org] > > > Sent: Thursday, May 20, 2004 5:34 PM > > > > > > > > > Ha! funny you should ask that exactly now.. > > > I was just discussing this with Robert Watson.. > > > > > > The answer is "it depends on what you want to do". > > > > > > What DO you want to do and what does your node do? > > > netgraph has internal locking in 5.x that you need to > > > interact with but it should be pretty transparrent > > > depending on what you are doing.. > > > > > > > > > On Thu, 20 May 2004, Dmitri Denissov wrote: > > > > > > > Hi, > > > > > > > > Currently netgraph code uses splnet/splx to protect > timeout calls. > > > > This doesn't work with 5.2 SMP kernel. What is the > proper method > > > > here for a custom netgraph node? Is the Giant lock only the way? > > > > > > > > Thanks > > > > > > > > -- > > > > Dmitri > > >