jamal wrote: > On Thu, 2006-06-04 at 18:29 +0200, Patrick McHardy wrote: > [..] > > >>There are basically two possibilities how to implement this. The less >>intrusive, but IMO more hackish one is to just handle this inside the >>qdiscs that require this operation by not requeueing the packet to >>the qdisc, but keeping a private reference somewhere. The disadvantage >>is that this distorts statistics and estimators, the classful qdisc >>would for example have more packets queued than the sum of all its >>inner qdiscs. The other possibility is to introduce a ->peek operation >>or a flag to ->dequeue and handle it within the reordering qdiscs. >>I think we only need to implement it for non-classful (or single-class) >>qdiscs, I can't imagine why anyone would add a scheduler as inner qdisc >>to a different scheduler, at least with the current ones. >> >>Any preferences or suggestions? Otherwise I'll go with the second >>possibility. >> > > > The second scheme looks better. The other way (mod to the second scheme) > is to have the dequeue "compensate for the last time" in the qdiscs i.e > if you over/undershot the last time because you computed lets say a > delay based on a packet which is no longer at the head of the queue then > you take that into account as well; note this suggestion implies it is > the non-work-conserving schedulers problem (which i think it is). > i.e those schedulers need to be fixed with a new assumption that "the > packet you got this time may not be the same as the last one you used to > compute next-time-to-give-an-skb".
After looking into it in more detail, it seems this problem doesn't really exist for reordering qdiscs that aren't schedulers. The packet that is handed out can only change for these when a higher priority packet is enqueued. In this case the containing scheduler will be dequeued immediately and will recalculate its timeout if it still needs to sleep. I'll verify that theory in my setup, which uses HFSC+SFQ. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
