From owner-svn-src-head@FreeBSD.ORG Thu Oct 17 04:54:47 2013 Return-Path: Delivered-To: svn-src-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id E2F38EFC; Thu, 17 Oct 2013 04:54:47 +0000 (UTC) (envelope-from glebius@FreeBSD.org) 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)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 6869C2140; Thu, 17 Oct 2013 04:54:46 +0000 (UTC) Received: from cell.glebius.int.ru (localhost [127.0.0.1]) by cell.glebius.int.ru (8.14.7/8.14.7) with ESMTP id r9H4siee081399; Thu, 17 Oct 2013 08:54:44 +0400 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebius.int.ru (8.14.7/8.14.7/Submit) id r9H4siF0081398; Thu, 17 Oct 2013 08:54:44 +0400 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.glebius.int.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Thu, 17 Oct 2013 08:54:44 +0400 From: Gleb Smirnoff To: Adrian Chadd Subject: Re: svn commit: r256587 - in head/sys: kern sys Message-ID: <20131017045444.GR52889@FreeBSD.org> References: <201310160502.r9G521cA066218@svn.freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "svn-src-head@freebsd.org" , "svn-src-all@freebsd.org" , "src-committers@freebsd.org" X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Oct 2013 04:54:48 -0000 On Wed, Oct 16, 2013 at 12:47:13PM -0700, Adrian Chadd wrote: A> .. so what brought this on? I can see this fixing issues for things where a A> virtual device is created with taskqueues (eg a tap device of some sort) A> that get stuffed into a vnet context. But for physical interfaces whose A> taskqueues don't have a specific vnet context and may need to set it A> per-packet, what may this break? For physical this shouldn't breab anything, you can re-set the curvnet, and then re-restore it. A> Ie - what did this fix, and why isn't it being fixed in all the various A> taskqueues in device drivers? A> A> I'd rather not see the taskqueue setup (which knows nothing about network A> contexts at all) grow this just to solve a bunch of places where the task A> in question can just correctly initialise the context itself when it's A> called. For non-physical drivers' taskqueues that fixes that taskqueue belongs to the same vnet, that was used on its creation. This is the case for pf(4), might be used somewhere else, for example tap(4) you mentioned. -- Totus tuus, Glebius.