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>