From owner-freebsd-net@FreeBSD.ORG Wed Nov 19 12:58:05 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E8FBAAAE; Wed, 19 Nov 2014 12:58:04 +0000 (UTC) Received: from mail.fer.hr (mail.fer.hr [161.53.72.233]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.fer.hr", Issuer "TERENA SSL CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4D1361F3; Wed, 19 Nov 2014 12:58:03 +0000 (UTC) Received: from x23 (31.147.125.196) by MAIL.fer.hr (161.53.72.233) with Microsoft SMTP Server (TLS) id 14.2.342.3; Wed, 19 Nov 2014 13:56:50 +0100 Date: Wed, 19 Nov 2014 13:56:51 +0100 From: Marko Zec To: "Alexander V. Chernikov" Subject: Re: RFC: Enabling VIMAGE in GENERIC Message-ID: <20141119135651.789c6766@x23> In-Reply-To: <546C8812.2070904@FreeBSD.org> References: <1423616F-F44D-47E5-8595-DE862DC04464@bsdimp.com> <546A34C8.6060004@freebsd.org> <546C8812.2070904@FreeBSD.org> X-Mailer: Claws Mail 3.9.2 (GTK+ 2.24.19; amd64-portbld-freebsd9.1) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Originating-IP: [31.147.125.196] Cc: Craig Rodrigues , FreeBSD Net , "freebsd-virtualization@freebsd.org" , Warner Losh , freebsd-arch X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Nov 2014 12:58:05 -0000 On Wed, 19 Nov 2014 16:07:46 +0400 "Alexander V. Chernikov" wrote: ... > Can we have some wiki/man/docs on how particular subsystem should > interact with VNET first? > This can probably help to make proper vnet fixes in less number of > attempts :) > > For example, even attach/detach is handled differently in different > places: > > tcp_subr.c: > /* Skip initialization of globals for non-default instances. > */ if (!IS_DEFAULT_VNET(curvnet)) > return; > in6_rmx.c: > /* > * Initialize our routing tree. > */ > static VNET_DEFINE(int, _in6_rt_was_here); > #define V__in6_rt_was_here VNET(_in6_rt_was_here) > > if (V__in6_rtwas_here == 0) { > callout_init(&V_rtq_mtutimer, CALLOUT_MPSAFE); > in6_mtutimo(curvnet); /* kick off timeout first > time */ V__in6_rt_was_here = 1; > } > > return (1); > } > > It would be great to get a bit more details on the following (at > least from my point of view): > * what is the proper procedure of handling non-default VNET > attach/detach (locking mostly) In general, VNET_SYSINIT() / VNET_SYSUNINIT() macros should be used to invoke per-subsystem ctors / dtors on per-vnet basis. > * how can one properly cache needed VNET context (e.g. is it safe > just to save "struct vnet *" pointer) and is this right thing to do > at all? Caching a VNET context should be avoided, as it yields similar problems as queuing mbufs does (in dummynet or similar queues) pointing to rcvifs which may disappear by the time the mbuf gets dequeued. > * Is it safe to to CURVNET_SET without holding any VNET locks ? Yes, if the VNET context is derived from some of the arguments in the current call graph. > P.S. I'm not against VIMAGE in any kind, I think we really should > move forward towards making it stable. > However, "just turn it on" concept with a bunch of known (and > unresolved issues) is not the best thing IMO. > > > > We have about 1 year until 11-RELEASE, so I think it is OK to do > > this. > > > > I would also add two items to my action plan. > > > > > > (6) Ask clusteradm to run one of the machines they use > > for PF firewalls + IPv6 with a VIMAGE enabled kernel, and > > provide feedback. > > > > (7) Ask for help with testing from companies who have more > > involvement with the network stack. Two of the people in the CC: > > line of this e-mail work for such places. :) > > > > -- > > Craig > > > > > > -- > > Craig > > _______________________________________________ > > freebsd-net@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-net > > To unsubscribe, send any mail to > > "freebsd-net-unsubscribe@freebsd.org" > > > > _______________________________________________ > freebsd-virtualization@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization > To unsubscribe, send any mail to > "freebsd-virtualization-unsubscribe@freebsd.org"