[Click] Notifications

[Eddie Kohler]

Hi,

Notification uses bits allocated in words.  Every notifier corresponds to 
exactly one bit.  Each Queue has two notifiers, which tend to be allocated out 
of the same word (since they are allocated in sequence).  Checking a set of 
notifiers is implemented as checking a set of bits in some word.  This works 
well in the common case that all the necessary bits were allocated in the same 
word.  But in your example, using the current allocation strategy, all the 
bits don't fit in a single word.  As a result Click falls back on the 
conservative assumption that the notifier is always on.

Eddie



Lars Bro wrote:
> Hi, 
> 
> In the following Click script:
> 
> 
> s::PrioSched;
> 
> Idle -> Queue -> [0]s;
> Idle -> Queue -> [1]s;
> Idle -> Queue -> [2]s;
> Idle -> Queue -> [3]s;
> Idle -> Queue -> [4]s;
> Idle -> Queue -> [5]s;
> Idle -> Queue -> [6]s;
> Idle -> Queue -> [7]s;
> Idle -> Queue -> [8]s;
> Idle -> Queue -> [9]s;
> Idle -> Queue -> [10]s;
> Idle -> Queue -> [11]s;
> Idle -> Queue -> [12]s;
> Idle -> Queue -> [13]s;
> Idle -> Queue -> [14]s;
> Idle -> Queue -> [15]s;
> // Idle -> Queue -> [16]s;
> 
> s->Unqueue -> Print -> Discard;
> 
> This example should do nothing at all.
> If I enable input # 16, the Unqueue element starts looping. It seems
> that the Unqueue element believes that there is a reason for waking up
> when the PrioSched element has more than 16 inputs. The PrioSched
> correctly finds out that none of the signals are active, and returns
> nothing. The Unqueue expects to be put to sleep, otherwise it will loop
> until it gets _bursts packets.
> 
> Yours,
> Lars Bro
> 
> _______________________________________________
> click mailing list
> click at amsterdam.lcs.mit.edu
> https://amsterdam.lcs.mit.edu/mailman/listinfo/click