[Click] Queues and notifications

[Geoffrey Lefebvre]

Hi,

I think I might have an idea of what the problem is (and I also
realize that was understanding signals backwards... :)). Here is a
tentative fix that solves the problem for me (userspace and linux)

I am using 1.5 so I don't know if that has been fixed in the CVS version.

In Notifer::upstream_empty_signal().  The signal is set only once even
if a second pass is needed to gather all notifers.  Updating the
signal seems to fix the problem (for me anyway). See below.

cheers,

geoffrey



    int ok = e->router()->upstream_elements(e, port, &filter, v);

    NotifierSignal signal = filter._signal;

    // maybe run another pass
    if (ok >= 0 && signal != NotifierSignal() && filter._need_pass2) {
        filter._pass2 = true;
        ok = e->router()->upstream_elements(e, port, &filter, v);

        //POTENTIAL FIX
        signal = filter._signal;

    }

On 1/25/07, Eddie Kohler <kohler at cs.ucla.edu> wrote:
> Clearly something is wrong with Click's notifications, with the number
> of people reporting problems, yet this config, with Queues instead of
> SimpleQueues, works for me!!
>
> Anyone got any ideas?
>
> Confused,
> E
>
>
> Mike Wilson 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
> _______________________________________________
> click mailing list
> click at amsterdam.lcs.mit.edu
> https://amsterdam.lcs.mit.edu/mailman/listinfo/click
>