[altq 94] Re: Some questons about cutoff_

[Kenjiro Cho <kjc@csl.sony.co.jp>]

>> I have some questions about the setting of cutoff_. I don't understand
>> it so well, so please correct me if you think what I describe below is
>> not correct!

cutoff_ is used for a heuristic algorithm and we don't know the
CORRECT way to do that...

>> My quesitons are
>> 1:
>> In line 1079 of _rmc_wrr_dequeue_next() in altq_rmclass.c
>>     1079: ifd->cutoff_ = cl->borrow_->depth_;
>> and line 11979 of _rmc_prr_dequeue_next() in altq_rmclass.c
>>     1079: ifd->cutoff_ = cl->borrow_->depth_;
>> Why does it set cutoff_ to the new value?

It is more consistent with the definition of the top-lvel:

	the class has an underlimit ancestor whose lvel is at most
	top-level.

>> 2: I guess that from line 1490 of rmc_update_class_util() in
>> altq_rmclass.c implements rule 3
[snip]
>> I don't understand line 1492, why the condition is not
>> qlen(cl->q_) <= 0
>> But is qlen(cl->q_) <= 1

I just inherited it from the original.   Do you see any negative
effect of comparing with 1?

>> I also don't understand line 1490,
>> 1490:  if (borrowed && (ifd->cutoff_ >= borrowed->depth_))
>> why we reset the cutoff_ value only if a class borrowed.
[snip]
>> the condition in
>> 1490:  if (borrowed && (ifd->cutoff_ >= borrowed->depth_))
>> would fail and not to modify the cutoff_ value. But actually, the
>> sending class is no more unsatisfied(underlimit but still has packets to
>> send), the cutoff_ value should be modifed.

It is ok to simply descrease cutoff_ but we must be careful when
increasing cutoff_.
So, the next scheduling loop takes care of increasing cutoff_.

-Kenjiro