From owner-freebsd-net  Tue Nov 21 10: 0:17 2000
Delivered-To: freebsd-net@freebsd.org
Received: from inetfw.sonycsl.co.jp (inetfw.SonyCSL.CO.JP [203.137.129.4])
	by hub.freebsd.org (Postfix) with ESMTP id 92BC737B4C5
	for <net@freebsd.org>; Tue, 21 Nov 2000 10:00:01 -0800 (PST)
Received: from hotaka.csl.sony.co.jp (hotaka.csl.sony.co.jp [43.27.98.57])
	by inetfw.sonycsl.co.jp (8.9.3+3.2W/3.7Ws3/inetfw/2000050701/smtpfeed 1.07) with ESMTP id CAA37983;
	Wed, 22 Nov 2000 02:59:59 +0900 (JST)
Received: from localhost (localhost [127.0.0.1])
	by hotaka.csl.sony.co.jp (8.9.3+3.2W/3.7Ws3/hotaka/2000061722) with ESMTP id CAA78742;
	Wed, 22 Nov 2000 02:59:59 +0900 (JST)
To: julian@elischer.org
Cc: net@freebsd.org
Subject: Re: ALTQ as standard.....
In-Reply-To: <3A1A74D4.CF5AEF4F@elischer.org>
References: <3A1A74D4.CF5AEF4F@elischer.org>
X-Mailer: Mew version 1.94.2 on Emacs 20.6 / Mule 4.0 (HANANOEN)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <20001122025959Z.kjc@csl.sony.co.jp>
Date: Wed, 22 Nov 2000 02:59:59 +0900
From: Kenjiro Cho <kjc@csl.sony.co.jp>
X-Dispatcher: imput version 20000228(IM140)
Lines: 53
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.org


ALTQ can be viewed as
  (1) abstraction of the output queue
and
  (2) an implementation based on (1)

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


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message