[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[altq 1486] Re: Another source of HFSC-ALTQ unfairness
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:)).
> 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?
> 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.