From owner-freebsd-hackers Wed Sep 26 10:46: 0 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from InterJet.elischer.org (c421509-a.pinol1.sfba.home.com [24.7.86.9]) by hub.freebsd.org (Postfix) with ESMTP id 4AF4B37B428 for ; Wed, 26 Sep 2001 10:45:52 -0700 (PDT) Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id LAA60895; Wed, 26 Sep 2001 11:23:17 -0700 (PDT) Date: Wed, 26 Sep 2001 11:23:15 -0700 (PDT) From: Julian Elischer To: Maksim Yevmenkin Cc: hackers@freebsd.org Subject: Re: Netgraph feature request/suggestion In-Reply-To: <3BB1FF55.1460E1E4@digisle.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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 Hi! I'd love to hear more about what you are doing.. but to answer your questions.. Note: All this changes in -current where netraph was largely rewritten. On Wed, 26 Sep 2001, Maksim Yevmenkin wrote: > Hackers, > > 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". ok.. > > 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. yes, but I'l not sure what the problem is.... (Do you want C to notify B that it has room?) > > 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. Hooks have no methods at this time, but, yes we can add them should you be very convincing :-) > 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. The node can presently turn on the HK_QUEUE bit itself, but that will only delay the data for a short time.. It seesm to be that "C" needs to do it's own internal queueing. Is "C" an device driver? how does it get to run asynchronously? > > thanks, > max > > p.s. i think it should be easy to implement, if people are > interested. i can prepare the patches. > > p.p.s. if anyone knows nice solution to this problem please > let me know. Well in -current you could do it by locking the node C to serialise all accesses to it. You could also use the "flow control messages" defined in -current netgraph, to disable or re-enable data flow from "A". can you give me more information to help me understand the problem a bit better. > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message