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

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

Oleg Cherevko wrote:
> 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:)).

Good.

> 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?

Yes.  It was mainly for RSVP but I think not many people use it any more.

>    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? 

You know, modifying a class on the fly isn't easy :)
With my last patch, the runtime service curve is re-initialized when
the class is backlogged.  But you seem to have a different idea.

> 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?

Unfortunately, no.  I would use only the new service curve.

> 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? 

Yes.

>    If so, is it safe to call MALLOC() with M_WAITOK in between?

As itojun said, no.  It's my mistake.  MALLOC() should be taken out of
the spl block.

-Kenjiro