From owner-freebsd-hackers Wed Sep 26 9:44: 0 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from owa-sj-1.digisle.com (owa-sj-1.digisle.com [167.216.153.124]) by hub.freebsd.org (Postfix) with ESMTP id 0BFAB37B41C for ; Wed, 26 Sep 2001 09:43:57 -0700 (PDT) Received: from VWALL-SJ-1.digisle.com ([167.216.153.118]) by owa-sj-1.digisle.com with Microsoft SMTPSVC(5.0.2195.2966); Wed, 26 Sep 2001 09:45:12 -0700 Received: from 206.220.227.145 by VWALL-SJ-1.digisle.com (InterScan E-Mail VirusWall NT); Wed, 26 Sep 2001 09:43:58 -0700 Message-ID: <3BB205CB.257DEF76@digisle.net> Date: Wed, 26 Sep 2001 09:43:55 -0700 From: Maksim Yevmenkin Organization: Digital Island X-Mailer: Mozilla 4.78 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Luigi Rizzo Cc: hackers@FreeBSD.ORG Subject: Re: Netgraph feature request/suggestion References: <200109261622.f8QGMAl65454@iguana.aciri.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 26 Sep 2001 16:45:12.0187 (UTC) FILETIME=[9C3024B0:01C146AA] Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Luigi, [...] > one problem you have to keep in mind with what you want to do > (and i am not talking about the implementation that you suggest, > just the "delayed processing" aspects) is that sometimes data passed > through modules have a limited lifetime and might have become stale > by the time the consumer is scheduled to process them. that is why this feature must be *optional* and turned off by default. the node must decide whenever it wants to do delivery scheduling and on which hook. the node also must be prepared to deal with various nasty side effects. in my case it is not a big problem, but in general case there is always Netgraph "meta data". [....] > > i'm in the middle of the project that uses Netgraph. > > everything is going pretty good, but there is one small > > issue. in five words it is "message and data delivery > > scheduling". here is an example: > > > > Node A --> Node B --> Node C > > > > Node "A" forwards data/messages to Node "B" and Node "B" > > in its turn forwards data/messages to Node "C". the issue > > is that Node "C" can handle only some small amount of > > data/messages at a time. Node "B" is aware of Node "C"'s > > limitation and must perform "leaking bucket" type of > > scheduling. i.e. Node "B" must queue data inside itself > > and then schedule later delivery to Node "C". > > > > but that is not all. sometimes it is required to send > > chunk of data (several messages) from Node "A" to Node "C". > > (via Node "B") and until this chunk of data is processed by > > Node "C", Node "B" is not allowed to send/accept any more > > data. > > > > i know about kernel threads and task queue, but i would really > > like to stay within Netgraph infrastructure and do not perform > > any extra synchronization. > > > > here is the proposal. every hook has two extra methods > > "hk_RcvDataShed" and "hk_RcvmMgSched" that performs scheduling. > > Node can turn on delivery scheduling on one of its hook by > > setting these methods. before actual data/message delivery > > Netgraph will call these methods and ask destination node "is > > that a good time to deliver this data/message". if it is then > > delivery is performed. otherwise depending on "HK_QUEUE" bit > > data/message gets queued or dropped. or perhaps turning on > > delivery scheduling must turn on "HK_QUEUE" bit automatically. thanks, max To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message