From owner-freebsd-virtualization@FreeBSD.ORG Sat Jul 27 15:29:00 2013 Return-Path: Delivered-To: freebsd-virtualization@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 E8A87747; Sat, 27 Jul 2013 15:29:00 +0000 (UTC) (envelope-from zec@fer.hr) Received: from mail.fer.hr (mail.fer.hr [161.53.72.233]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 7869A29D2; Sat, 27 Jul 2013 15:29:00 +0000 (UTC) Received: from x23.lan (89.164.3.121) by MAIL.fer.hr (161.53.72.233) with Microsoft SMTP Server (TLS) id 14.2.342.3; Sat, 27 Jul 2013 17:28:57 +0200 From: Marko Zec To: Adrian Chadd Subject: Re: De-virtualize V_pf_mtag_z to eliminate kernel panics. Date: Sat, 27 Jul 2013 17:28:56 +0200 User-Agent: KMail/1.9.10 References: <201307271619.51409.zec@fer.hr> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-ID: <201307271728.56777.zec@fer.hr> X-Originating-IP: [89.164.3.121] Cc: Gleb Smirnoff , "freebsd-virtualization@freebsd.org" , freebsd-pf@freebsd.org X-BeenThere: freebsd-virtualization@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Discussion of various virtualization techniques FreeBSD supports." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Jul 2013 15:29:01 -0000 On Saturday 27 July 2013 16:48:00 Adrian Chadd wrote: > I'm happy keeping it virtual (it lets us do things like set per-vimage > mbuf tag limits, and having per-vimage mbufs may be a useful long term > stretch goal to have).. we just have to think about this stuff in more > detail. The V_pf_mtag_z zone apparently doesn't have any size limits, so it doesn't enforce mbuf tag limits in pf, and certainly it doesn't enforce any limits outside of PF? And while otherwise I wouldn't terribly object to keep V_pf_mtag_z virtual, if we don't de-virtualize it, would you have an alternative proposal to resolve the panics in PF which Craig wants to have fixed? Finally, while the idea about enforcing per-vnet mbuf (and tag) limits may look neat on the surface, the fact that mbufs may flow freely between vnets makes this idea less trivial to implement than it may appear at the first glance. In any case, IMO that issue is entirely unrelated to the patch Craig proposed, and should be discussed separately. Marko