From owner-freebsd-hackers Sat May 16 11:11:09 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id LAA15048 for freebsd-hackers-outgoing; Sat, 16 May 1998 11:11:09 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from widefw.csl.sony.co.jp (widefw.csl.sony.co.jp [133.138.1.1]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id LAA15008; Sat, 16 May 1998 11:10:59 -0700 (PDT) (envelope-from kjc@csl.sony.co.jp) Received: from hotaka.csl.sony.co.jp (root@hotaka.csl.sony.co.jp [43.27.98.57]) by widefw.csl.sony.co.jp (8.8.8/3.6W) with ESMTP id DAA08474; Sun, 17 May 1998 03:10:57 +0900 (JST) Received: from localhost (kjc@[127.0.0.1]) by hotaka.csl.sony.co.jp (8.8.8/3.6W/hotaka/98021914) with ESMTP id DAA00252; Sun, 17 May 1998 03:10:56 +0900 (JST) Message-Id: <199805161810.DAA00252@hotaka.csl.sony.co.jp> To: Luigi Rizzo cc: isp@FreeBSD.ORG, hackers@FreeBSD.ORG Subject: Re: Bandwidth limiter available In-reply-to: Your message of "Sat, 16 May 1998 17:26:00 +0200." <199805161526.RAA04372@labinfo.iet.unipi.it> Date: Sun, 17 May 1998 03:10:56 +0900 From: Kenjiro Cho Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Thanks Luigi for the clarification. In addition, modification to IF_DEQUEUE isn't enough. There are several drivers that peeks at if_snd or use IF_PREPEND; these operations don't work with multiple queues. If the drivers are written not to use these operations, replacing IF_DEQUEUE works fine. More details are described in my paper available at http://www.csl.sony.co.jp/person/kjc/papers/usenix98/ --Kenjiro Luigi Rizzo said: > Very fancy. Not what most isps are looking for, but useful. > > One question: why were the hooks put in the drivers rather than at a > higher , more generic level. The process does not have to be as intrusive > as ALTQ seems to be. Sounds like an ongoing maintenence nightmare. >> i guess you refer to ALTQ. The answer is, to do CBQ/WFQ you want >> to select the next packet to be sent at the time the interface asks >> for one. The current implementation of IF_DEQUEUE and friends >> instead implements a queue in front of the interface, and this can >> disturb the bandwidth allocation. >> If you just want a bandwidth limiter you can work at a higher level >> since each flow is scheduled independently of the others, so you don't >> care about what is downstream. >> One way to solve the mainteinance problem could be to make IF_DEQUEUE >> an upcall to a higher level queue-handling function, so that it can be >> modified independently of the device driver, and can work with >> binary-only drivers. But this still requires an upgrade of the driver >> once the transition is made. >> i don't know how many drivers are supplied in binary-only format. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message