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. _______________________________________________ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
