[altq 1483] Re: Another source of HFSC-ALTQ unfairness

[Oleg Cherevko <olwi@aq.ml.com.ua>]

Hi Kenjiro,

On Mon, 29 Apr 2002, Oleg Cherevko wrote:

> costy. I believe that I know how to reduce this cost without compromising 
> the idea. As I said earlier, I'd inform you on the results.

I finally implemented new init_v() algorithm as well as redesigned my
HAFSC extensions (the first version turned out to work only in certain
specific cases, new one should work OK in all cases (not tested yet:)).

I have a few questions about hfsc_class_modify() now:

1. Am I right that this function can be called anytime asynchronousely to
   the main HFSC activity?
   What actually bothers me is that in the case class service curves are
   modified while class is active it seems too simplistic just to call
   rtsc_init(&cl->cl_virtual, cl->cl_fsc, 0, 0) and alike. This may damage
   fair vt distribution among active sibling classes a lot.
   IMHO, something trickier is required. What do you think about this? 

2. When the service curve of the class is changed we may need to perform
   rtsc_min() on two *different* service curves (the old one and the new
   one) that may be even of different types (a.g., convex and concave).
   Was rtsc_min() designed to allow this?

3. Am I right, that s = splimp() in the beginning of hfsc_class_modify()
   inhibits normal HFSC packet scheduling activity until the splx(s)
   restores the appropriate interrupts priority level? 
   If so, is it safe to call MALLOC() with M_WAITOK in between?

-- 
Olwi