From owner-freebsd-net@FreeBSD.ORG Wed Apr 15 12:59:47 2015 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2FEC8764 for ; Wed, 15 Apr 2015 12:59:47 +0000 (UTC) Received: from cell.glebius.int.ru (glebius.int.ru [81.19.69.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "cell.glebius.int.ru", Issuer "cell.glebius.int.ru" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id C2777A60 for ; Wed, 15 Apr 2015 12:59:46 +0000 (UTC) Received: from cell.glebius.int.ru (localhost [127.0.0.1]) by cell.glebius.int.ru (8.14.9/8.14.9) with ESMTP id t3FCxiDn029292 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 15 Apr 2015 15:59:44 +0300 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebius.int.ru (8.14.9/8.14.9/Submit) id t3FCxiGA029291; Wed, 15 Apr 2015 15:59:44 +0300 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.glebius.int.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Wed, 15 Apr 2015 15:59:44 +0300 From: Gleb Smirnoff To: Luigi Rizzo Cc: "freebsd-net@freebsd.org" Subject: Re: moving ALTQ out of contrib Message-ID: <20150415125944.GD883@glebius.int.ru> References: <20150414135346.GU883@FreeBSD.org> <20150415073823.GA94402@onelab2.iet.unipi.it> <20150415122627.GZ883@glebius.int.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Apr 2015 12:59:47 -0000 On Wed, Apr 15, 2015 at 02:53:34PM +0200, Luigi Rizzo wrote: L> > L> > With the new ifnet KPI, that is now being developed in projects/ifnet, L> > L> > the ALTQ will need some tweaking. It is discontinued by initial author L> > L> > for a decade now, and it has already experienced direct commits in L> > L> > our tree. Thus, I see no good reasons to continue keeping it in contrib. L> > L> > In NetBSD they have it in sys/altq. L> > L> > L> > L> > I'd prefer to move it to sys/net/altq. L> > L> > L> > L> > Any objections or better ideas? L> > L> L> > L> my first question is what is the expected residual lifetime of altq ? L> > L> > If I get it working properly in projects/ifnet, I see no reasons to L> > remove it. It is going to be a plugin into network stack and will no L> > longer require editing drivers. It will run on drivers that aren't L> > supported by ALTQ now. However in the latter case the ALTQ will sit L> > on top of interface own queue, and will start to work only when L> > interface's own queue overflows. But if we later add a new interface L> > method to modify length of own queue at runtime, this issue will L> > go away. L> > L> > L> If it is destined to be removed soon (and probably that is not L> > L> unlikely given its unmaintained state, the absence of multiqueue L> > L> support etc.) maybe we could live for the next L> > L> couple of years just leaving it where it is now and avoid the L> > L> repo churn. L> > L> L> > L> If we really plan to relocate the code, I guess the options are L> > L> L> > L> sys/altq as in netbsd L> > L> L> > L> sys/netaltq this would be an alternative location to L> > L> the above one, justified by the fact that L> > L> we have already a bunch of net* subdirs L> > L> L> > L> sys/net/altq as you propose, i guess to stay close to L> > L> the rest of the ifnet code (and perhaps L> > L> as a first step in cleaning up sys/net L> > L> by putting stuff in various subdirs) L> > L> L> > L> In any case my preference would really be to leave it where it is. L> > L> > I don't like to keep in contrib a code maintained and edited by the L> > project. Especially I don't like tautological path of contrib/altq/altq. L> > I don't like extra glue in Makefiles, especially modyfing CFLAGS for the L> > whole kernel build. L> > L> > If it is a regular piece of kernel code, let it be like the rest of L> > kernel code. L> L> ok thanks for the clarification. L> L> Then if you do sys/net/altq/ do you also plan to split the current L> content of sys/net/ into separate subdirectories ? L> L> We currently have quite a few separate things in sys/net/, such as L> - various bpf files L> - generic ifnet support (including raw sockets) L> - various libraries (compression and hash functions) L> - routing code L> - bridging code L> - a ton of special ifnets, (tun, tap, epair, gif, ....) L> - bridging code L> that could benefit from a bit of partitioning I definitely agree that a) special interfaces b) lagg+lacp c) generic libraries should be separated. I don't mind if anyone does this job :) But I personally would prefer is this is done after the lifetime of the projects/ifnet branch, since if stuff is moved while I work on projects/ifnet, my merging will become a nightmare. I already have conflicts quite often. -- Totus tuus, Glebius.