From owner-freebsd-net@FreeBSD.ORG Tue Oct 29 20:50:28 2013 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 77851A24 for ; Tue, 29 Oct 2013 20:50:28 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id DB88625EE for ; Tue, 29 Oct 2013 20:50:27 +0000 (UTC) Received: (qmail 57757 invoked from network); 29 Oct 2013 21:20:57 -0000 Received: from c00l3r.networx.ch (HELO [127.0.0.1]) ([62.48.2.2]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 29 Oct 2013 21:20:57 -0000 Message-ID: <52701F7E.2060604@freebsd.org> Date: Tue, 29 Oct 2013 21:50:06 +0100 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: Randall Stewart , Luigi Rizzo Subject: Re: MQ Patch. References: <40948D79-E890-4360-A3F2-BEC34A389C7E@lakerest.net> <526FFED9.1070704@freebsd.org> <13BF1F55-EC13-482B-AF7D-59AE039F877D@lakerest.net> In-Reply-To: <13BF1F55-EC13-482B-AF7D-59AE039F877D@lakerest.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Cc: "freebsd-net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Oct 2013 20:50:28 -0000 On 29.10.2013 21:20, Randall Stewart wrote: >> So, to conclude: i fully support any plan to design something that lets us >> implement scheduling (and qos, if you want to call it this way) >> in a reasonable way, but what is in your patch now does not really >> seem to improve the current situation in any way. > > Its a step towards fixing that I am allowed to give. I can see > why Company's get frustrated with trying to give anything to the project. Well, that we have a problem in that area is known and acknowledged and there is active work in this area going on. It would be very problematic if every vendor were just to through some stuff over the fence and have it integrated as is. It would quickly become very messy. In many specific purpose geared products a number of shortcuts can be taken that may not be appropriate for a general purpose OS that does more than routing. I believe we value the contribution by Adara and you but at the same time want to integrate it into a bigger picture for the entire kernel. When you pull up your product to FreeBSD 11 in the future it should be easy to stack your functionality again on the new base infrastructure without many/any modifications. -- Andre