Date: Thu, 23 Nov 2000 05:03:52 -0800 From: Julian Elischer <julian@elischer.org> To: Kenjiro Cho <kjc@csl.sony.co.jp> Cc: net@freebsd.org Subject: Re: ALTQ as standard..... Message-ID: <3A1D15B8.167B4A90@elischer.org> References: <3A1A74D4.CF5AEF4F@elischer.org> <20001122025959Z.kjc@csl.sony.co.jp>
next in thread | previous in thread | raw e-mail | index | archive | help
Kenjiro Cho wrote:
>
> ALTQ can be viewed as
> (1) abstraction of the output queue
> and
> (2) an implementation based on (1)
What I want to see standard is the abstraction part..
if that's suppplied the rest can be a module...
>
> I'd like to focus on (1) for our discussion for the moment.
>
> The output queue is the place where packet scheduling and buffer
> management can be done.
> The current IF macros are incomplete (e.g., lack of a poll operation),
> and its model lacks enough abstraction to accommodate algorithms other
> than FIFO.
>
> I'm trying to make the output queue as a black-box with a set of
> well-defined operations, and modify the existing code to access the
> output queue only through these operations.
> Although we have to first convert the existing drivers to use these
> operations, I believe it will pay off in the long run.
>
> Once we have a clean model of the output queue, modifications to the
> internal structure do not affect the other part of the kernel, be it
> ALTQ or another implementation.
> (this approach is also preferable for SMP.)
>
> In ALTQ, the following 4 operations are used.
> - ENQUEUE
> enqueues a packet to the queue. ENQUEUE also takes care of
> packet dropping. if the arriving packet is dropped, the mbuf
> is freed and an error (ENOBUFS) is returned.
> - DEQUEUE
> dequeues a packet from the queue.
> - POLL
> returns the next packet without removing the packet from the
> queue.
> if DEQUEUE immediately follows POLL, the same packet is
> returned. (locking will be needed for SMP.)
> - PURGE
> discards all the packets in the queue. (this operation is
> needed for non-work conserving schedulers which cannot get
> emptied by a dequeue-loop.)
>
> In this model, a driver can poll-and-dequeue a packet but cannot
> prepend a packet back to the queue because it could be too expensive
> for some algorithms to cancel scheduling once the internal state is
> updated.
> Thus, if a driver currently use "prepend-if-failed", it should be
> converted to "poll-and-dequeue".
>
> I'll write a brief design note in a week (so that I can submit it to
> Freenix). I'll post it to the list when I'm done.
>
> -Kenjiro
--
__--_|\ Julian Elischer
/ \ julian@elischer.org
( OZ ) World tour 2000
---> X_.---._/ presently in: Budapest
v
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3A1D15B8.167B4A90>