Date: Wed, 15 Apr 2015 15:42:28 +0300 From: Gleb Smirnoff <glebius@FreeBSD.org> To: Ermal =?iso-8859-1?Q?Lu=E7i?= <eri@freebsd.org> Cc: Luigi Rizzo <rizzo@iet.unipi.it>, "net@freebsd.org" <net@freebsd.org> Subject: Re: moving ALTQ out of contrib Message-ID: <20150415124228.GA883@glebius.int.ru> In-Reply-To: <CAPBZQG0Ripz6vKb57zUhuL%2BnE2kQOG6C2aaOSAm0MyRDF4dyQQ@mail.gmail.com> References: <20150414135346.GU883@FreeBSD.org> <20150415073823.GA94402@onelab2.iet.unipi.it> <20150415122627.GZ883@glebius.int.ru> <CAPBZQG0Ripz6vKb57zUhuL%2BnE2kQOG6C2aaOSAm0MyRDF4dyQQ@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Apr 15, 2015 at 02:38:21PM +0200, Ermal Luçi wrote: E> > projects/ifnet, E> > L> > the ALTQ will need some tweaking. It is discontinued by initial author E> > L> > for a decade now, and it has already experienced direct commits in E> > L> > our tree. Thus, I see no good reasons to continue keeping it in E> > contrib. E> > L> > In NetBSD they have it in sys/altq. E> > L> > E> > L> > I'd prefer to move it to sys/net/altq. E> > L> > E> > L> > Any objections or better ideas? E> > L> E> > L> my first question is what is the expected residual lifetime of altq ? E> > E> > If I get it working properly in projects/ifnet, I see no reasons to E> > remove it. It is going to be a plugin into network stack and will no E> > longer require editing drivers. It will run on drivers that aren't E> > supported by ALTQ now. However in the latter case the ALTQ will sit E> > on top of interface own queue, and will start to work only when E> > interface's own queue overflows. But if we later add a new interface E> > method to modify length of own queue at runtime, this issue will E> > go away. E> > E> E> I would be interested on your approach on this as well. E> Also i can remind you that dragonflybsd has made some work on it to support E> multiqueue. E> IIRC they even mapped the queues directly the hardware queues so it might E> be interesting to look at their approach if it applies. The latter is definitely a better design. However, it requires much more work. My plan for now is just keep the ALTQ supported with removal of 'struct ifqueue' from 'struct ifnet' and at the same time provide a proof of concept code, that demonstrates that a shaping system can be a plugin shim in place of if_transmit method. Actually, I've been told that Yandex already had such a shaping system, so proof of concept already exists, but not open sourced. -- Totus tuus, Glebius.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20150415124228.GA883>