From owner-freebsd-hackers Wed Sep 26 11:32:20 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 B04C937B42B for ; Wed, 26 Sep 2001 11:32:12 -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 11:33:27 -0700 Received: from 206.220.227.145 by VWALL-SJ-1.digisle.com (InterScan E-Mail VirusWall NT); Wed, 26 Sep 2001 11:32:14 -0700 Message-ID: <3BB21F2A.F4ABE2D9@digisle.net> Date: Wed, 26 Sep 2001 11:32:10 -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: Julian Elischer Cc: hackers@freebsd.org Subject: Re: Netgraph feature request/suggestion References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 26 Sep 2001 18:33:27.0833 (UTC) FILETIME=[BBE51090:01C146B9] 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 Julian, [...] > All this changes in -current where netraph was largely rewritten. i know. i'm using current > > 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?) yes. Node "C" sends periodic notification to Node "B". the easy solution here is to send one data/message at a time and wait until "C" sends notification back or timeout occur, then "B" will schedule another delivery (if any). but it kills the performance. and, like i said before, sometimes i just need to send chunk of data and wait for notification from "C" or for timeout. and in the same time i do not want keep "A" waiting. [....] > > 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 :-) perhaps i should have used another word. -current Netgraph "ng_hook" structure has "hk_rcvmsg" and "hk_rcvdata" function pointers and node can set different message/data receive function per hook. suggestion was to add two more function pointers. i called them methods. > > 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. there can be multiply instances of "C". i do not want to duplicate this code in every "C" instance. > Is "C" an device driver? how does it get to run asynchronously? it could be a device driver, or it could be another node. it does not really matter (i think). and, yes, it does run asynchronously. that is why i do not want to mess around threads and task queues. extra overhead of locking etc. [...] > 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". hmmm... i should look into it. > can you give me more information to help me understand > the problem a bit better. i hope this helps, thanks, max To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message