[Click] Queues and notifications

Geoffrey Lefebvre geoffrey.lefebvre at gmail.com
Thu Jan 25 16:20:19 EST 2007


Hi,

This seems similar to the problem I am experiencing with   ... ->
Queue -> DelayShaper -> ToDevice.  From debugging I know that both the
DelayShaper and the ToDevice elements are registered with the
_empty_note notifier in the Queue. I also know that only the bit
corresponding to the DelayShaper is set in _empty_note's signal.

When _empty_note.wake() is called the ToDevice 's task is scheduled
(the DelayShaper isn't scheduled since it doesn't have a task). The
task runs but since its signal isn't set, it returns immediatly. I
have worked around the problem by adding a task to DelayShaper that
simply calls wake() on its notifier to trigger a pull from downstream.

I am trying to understand the behavior of signals. When a Notifier
sets its signal, shouldn't it set the signal of all listeners
registered with it? (ie is a derived signal the OR of all the base
signal of pull elements that are downsteam of the notifier?)


Below is another simple config that triggers the problem. The counters
show that no packets ever leave q1 and reach ToDevice.

cheers,

geoffrey



InfiniteSource(DATA \<00 00 c0 ae 67 ef  00 00 00 00 00 00  08 00
45 00 00 28  00 00 00 00  40 11 77 c3  01 00 00 01
02 00 00 02  13 69 13 69  00 14 d6 41  55 44 50 20
70 61 63 6b  65 74 21 0a>, LIMIT 10, STOP false)
    -> Strip(14)
    -> CheckIPHeader()
    -> q0 :: Queue
    -> DelayUnqueue(1)
    -> c0 :: Counter
    -> q1 :: Queue
    -> DelayShaper(1)
    -> Unstrip(14)
    -> c1 :: Counter
    -> ToDevice(eth0);



On 1/25/07, Mike Wilson <mlw2 at arl.wustl.edu> wrote:
> I've got a large, complex click config where I read from UDP sockets and
> write to a raw socket, routing packets from UDP tunnels.  Unfortunately, I
> can't seem to get notifications working in the Queues.
>
> I've stripped the config down to a fairly simple case that replicates the
> problem, at least on my system.  If I use Queue or NotifierQueue
> components for the queues, I either get nothing out the interface, or I
> get 1-2 packets and then nothing.  If I use a SimpleQueue, everything
> works just fine.
>
> My limited understanding is that the SimpleQueue doesn't do notifiers, so
> the pull components downstream must use polling.  In other words, it's a
> massive CPU hog - I get 99% utilization to click with a SimpleQueue.  With
> Queue, I don't even see click in my top(1) list.
>
> Am I mis-using the queue components somehow, or is this a bug?  Do
> RawSockets use notifiers?
>
> -Mike Wilson
>
> ---replication example---
>
> // Warning, this config will send bogus UDP packets to 172.16.46.20.
> // Unfortunately, the problem doesn't manifest with a Discard at the end.
>
> AddressInfo(myip  128.252.160.209,
>              NetRtr 172.16.46.12,
>              HostRtr 172.16.46.20,
>              NetRoute 172.16.46.0/24);
>
> PortInfo(NetTun 0xA121,
>           HostTun 0xA122);
>
> out :: RawSocket("UDP");
> rt :: RangeIPLookup(NetRoute  0, HostRtr 1);
> sched :: DRRSched();
>
> TimedSource -> UDPIPEncap(HostRtr, 5005, HostRtr, 5005) ->
> IPPrint("Injecting Packet") -> check :: CheckIPHeader;
> Idle -> rt;
>
> check[1] -> Print("Injected Bad packet") -> Discard;
> check[0] -> IPPrint("Injected Valid Packet") -> GetIPAddress(16) -> rt;
>
> rt[0] -> UDPIPEncap(myip, NetTun, NetRtr, NetTun) -> IPPrint("Net Route")
> -> SimpleQueue -> [0]sched;
> rt[1] -> UDPIPEncap(myip, HostTun, HostRtr, HostTun) -> IPPrint("Host
> Route") -> SimpleQueue -> [1]sched;
>
> sched -> IPPrint("Sending") -> out;
>
> _______________________________________________
> click mailing list
> click at amsterdam.lcs.mit.edu
> https://amsterdam.lcs.mit.edu/mailman/listinfo/click
>


More information about the click mailing list