Date: Thu, 17 Oct 2013 09:00:15 +0400 From: Gleb Smirnoff <glebius@FreeBSD.org> To: Adrian Chadd <adrian@freebsd.org> Cc: "svn-src-head@freebsd.org" <svn-src-head@freebsd.org>, "svn-src-all@freebsd.org" <svn-src-all@freebsd.org>, "src-committers@freebsd.org" <src-committers@freebsd.org> Subject: Re: svn commit: r256587 - in head/sys: kern sys Message-ID: <20131017050015.GS52889@FreeBSD.org> In-Reply-To: <CAJ-VmokmOfMue6t82iAqo6UDxbQCF7wx_yyEKwZVQo-ewSyQEA@mail.gmail.com> References: <201310160502.r9G521cA066218@svn.freebsd.org> <CAJ-VmokmOfMue6t82iAqo6UDxbQCF7wx_yyEKwZVQo-ewSyQEA@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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? A> 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. Also, see http://lists.freebsd.org/pipermail/svn-src-head/2013-October/052359.html -- Totus tuus, Glebius.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20131017050015.GS52889>