From owner-freebsd-net@FreeBSD.ORG Tue Dec 11 21:49:24 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 01CE86B4 for ; Tue, 11 Dec 2012 21:49:24 +0000 (UTC) (envelope-from oppermann@networx.ch) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.freebsd.org (Postfix) with ESMTP id 569578FC15 for ; Tue, 11 Dec 2012 21:49:22 +0000 (UTC) Received: (qmail 9829 invoked from network); 11 Dec 2012 23:18:18 -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 ; 11 Dec 2012 23:18:18 -0000 Message-ID: <50C7AA58.5050909@networx.ch> Date: Tue, 11 Dec 2012 22:49:12 +0100 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: Adrian Chadd Subject: Re: igb and ALTQ in 9.1-rc3 References: <20121211075853.GU48639@FreeBSD.org> <1355231140.51621.YahooMailClassic@web121603.mail.ne1.yahoo.com> <50C74990.2090803@gmail.com> <50C79252.5000509@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Karim Fodil-Lemelin , =?ISO-8859-1?Q?Erma?= =?ISO-8859-1?Q?l_Lu=E7i?= , "Clement Hermann \(nodens\)" , freebsd-net 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, 11 Dec 2012 21:49:24 -0000 On 11.12.2012 22:36, Adrian Chadd wrote: > .. the ALTQ compatibility stuff for buf_ring and drbr_* is just plain ew. > > The question is, who is going to step up and make that work? I'm > certainly not going to; when I teach net80211 and ath(4) about > if_transmit, I'm going to do it in a way that breaks ALTQ. And it'll > stay broken until I've ironed out all of the 802.11 and driver related > kinks that exist, and then it'll only come back up once we've all come > up with a much more sensible way to stuff this kind of queue > management into our network drivers. > > We -know- we need a much more generic implementation of packet queue > management. Someone just needs to come up with one. :-) As I've said earlier I'm working and cleaning up of the stack/driver interface and API. It started out to better integrate the offload capabilities, reduce code duplication and to audit their usage in the drivers. While doing that I've noticed, as others have, a couple more issues including the queuing problem. So work is under way and by early next year a prototype for further discussion should be ready. -- Andre