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 [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
