Date: Wed, 26 Sep 2001 09:43:55 -0700 From: Maksim Yevmenkin <myevmenk@digisle.net> To: Luigi Rizzo <rizzo@aciri.org> Cc: hackers@FreeBSD.ORG Subject: Re: Netgraph feature request/suggestion Message-ID: <3BB205CB.257DEF76@digisle.net> References: <200109261622.f8QGMAl65454@iguana.aciri.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3BB205CB.257DEF76>