Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 26 Sep 2001 11:32:10 -0700
From:      Maksim Yevmenkin <myevmenk@digisle.net>
To:        Julian Elischer <julian@elischer.org>
Cc:        hackers@freebsd.org
Subject:   Re: Netgraph feature request/suggestion
Message-ID:  <3BB21F2A.F4ABE2D9@digisle.net>
References:  <Pine.BSF.4.21.0109261113320.60777-100000@InterJet.elischer.org>

next in thread | previous in thread | raw e-mail | index | archive | help
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




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3BB21F2A.F4ABE2D9>