From owner-freebsd-net@freebsd.org Mon Jan 4 01:33:26 2016 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 43F19A61E89; Mon, 4 Jan 2016 01:33:26 +0000 (UTC) (envelope-from wollman@hergotha.csail.mit.edu) Received: from hergotha.csail.mit.edu (wollman-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:ccb::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 0733D178A; Mon, 4 Jan 2016 01:33:25 +0000 (UTC) (envelope-from wollman@hergotha.csail.mit.edu) Received: from hergotha.csail.mit.edu (localhost [127.0.0.1]) by hergotha.csail.mit.edu (8.14.9/8.14.9) with ESMTP id u041XN4G071894; Sun, 3 Jan 2016 20:33:23 -0500 (EST) (envelope-from wollman@hergotha.csail.mit.edu) Received: (from wollman@localhost) by hergotha.csail.mit.edu (8.14.9/8.14.4/Submit) id u041XM7m071891; Sun, 3 Jan 2016 20:33:22 -0500 (EST) (envelope-from wollman) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <22153.52194.769839.15339@hergotha.csail.mit.edu> Date: Sun, 3 Jan 2016 20:33:22 -0500 From: Garrett Wollman To: "Matthew D. Fuller" Cc: bz@freebsd.org, freebsd-net@freebsd.org, freebsd-stable@freebsd.org Subject: Re: Have I got this VIMAGE setup correct? In-Reply-To: <20151223044233.GM33115@over-yonder.net> References: <22137.33475.645324.203196@hergotha.csail.mit.edu> <20151223044233.GM33115@over-yonder.net> X-Mailer: VM 7.17 under 21.4 (patch 22) "Instant Classic" XEmacs Lucid X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (hergotha.csail.mit.edu [127.0.0.1]); Sun, 03 Jan 2016 20:33:23 -0500 (EST) X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED, HEADER_FROM_DIFFERENT_DOMAINS autolearn=disabled version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on hergotha.csail.mit.edu 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: Mon, 04 Jan 2016 01:33:26 -0000 < said: >> 2) Stopping jails with virtual network stacks generates warnings from >> UMA about memory being leaked. > I'm given to understand that's Known, and presumably Not Quite Trivial > To Fix. Since I'm not starting/stopping jails repeatedly as a normal > runtime thing, I'm ignoring it. If you were spinning jails up and > down dynamically dozens of times a day, I'd want to look more closely > at just what is leaking and why... It looks like that's what bz@ fixed in r292601 (thanks to rodrigc@ for pointing me in the right direction). I haven't looked at how difficult this would be to backport, but since I'm in the same situation as you in terms of the frequency of startup/teardown operations, I'm probably not going to worry too much about it. Other relevant changes from HEAD appear to be 292603, 292604, 278766, and 286537 (and again, this is just based on scanning the svn logs, not actually thinking about the code). > Is what I'm doing, though I'm creating the epair's and adding them to > the bridges in the setup script rather than rc.conf (exec.prestart in > jail.conf), because that makes it a more manageable IME, and since I'm > already doing a bunch of setup in the script anyway... For now, I think I'll just use exec.prestart to manually configure a MAC address. It would be nice if the LAA MAC addresses we generated were both random on initial creation (to better avoid duplicates) and stable over reboot. (Likewise the bridge(4) MAC address.) Or alternatively if we just had rc.conf support for explicitly configuring the MAC address of every interface, since ifconfig doesn't let you configure L2 and L3 addresses on the same command line. Actually, what would be *really* nice -- and I don't know if any of my network interfaces can do this, but it would give me a reason to buy hardware that could -- would be if PCI virtual functions could be used to implement multiple independent network interfaces in the same kernel (additional units in the same driver). Then I wouldn't have to deal with any of this configuration at all. Failing all of those, having a good, well-documented example in the handbook would be a Good Thing. -GAWollman