[altq 705] Re: ALTQ inbound processing

[Lars Eggert <larse@ISI.EDU>]

> 
> Lars Eggert wrote:
>>> ALTQ doesn't support queueing disciplines on the input path but
>>> diffserv-style traffic conditioning is supported.
>> 
>> You mean dropping packets that fall outside certain specified service level
>> limits? (Sorry, I'm not too familiar with diffserv terminology.)
> 
> You can also mark packets for differentiated treatment by the
> queueing disciplines along the path.
> 
>> If so, that's unfortunately not fine-grained enough for what I'm looking
>> into. Is there anything fundamental that would prohibit ALTQ from working on
>> the inbound queue? I've looked into is a little bit, and it seems to be a
>> straightforward extension (basically, ALTQify ipintrq). If that's the case,
>> I'll start working on it soon...
> 
> The problem is that input queues are empty most of the time so that
> there isn't much to do with queueing.

I agree with you that for a router, this is not an issue. However, I'm using
ALTQ on the end hosts, as part of a larger system.

Please let me give you a little more background information, so you know why
I'm interested in this, and why I think for my scenario input queue control
makes sense. The big picture is that I'm developing (host) OS extensions to
allow background use of any idle resources in the system. One example is the
CPU, for which POSIX idle-time scheduling (hard priorities, possibly
infinite preemption) basically gets me most of the way there.

For network service, ALTQ priq with two service classes seems to address my
requirements (I just started using ALTQ, not much experience with it yet).
However, the inbound queue isn't managed.

If I have a "background" packet queued in the ipintrq and a "foreground"
packet comes in, the "foreground" packet should be dequeued before the
"background" one. (Also, "background" ones should be dropped for queue space
first, etc.)

While this seems like a relatively minor issue in terms of performance
impact, it becomes important in light of the big picture: If you can utilize
idle resources "for free", then you'll try to keep them utilized at 100%. In
that scenario, the input queue can become the bottleneck controlling overall
system behavior: On the end systems (where I place my focus), packet
dequeueing from ipintr indirectly controls which processes become runnable,
and so forth.

-- 
Lars Eggert <larse@isi.edu>                   Information Sciences Institute
http://www.isi.edu/larse/                  University of Southern California