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 [EMAIL PROTECTED]
> with "unsubscribe freebsd-hackers" in the body of the message
>
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
