Date: Wed, 19 Nov 2014 13:56:51 +0100 From: Marko Zec <zec@fer.hr> To: "Alexander V. Chernikov" <melifaro@freebsd.org> Cc: Craig Rodrigues <rodrigc@freebsd.org>, FreeBSD Net <freebsd-net@freebsd.org>, "freebsd-virtualization@freebsd.org" <freebsd-virtualization@freebsd.org>, Warner Losh <imp@bsdimp.com>, freebsd-arch <freebsd-arch@freebsd.org> Subject: Re: RFC: Enabling VIMAGE in GENERIC Message-ID: <20141119135651.789c6766@x23> In-Reply-To: <546C8812.2070904@FreeBSD.org> References: <CAG=rPVccq7R5%2Bcbm6nR1WCZDM=-xwwkmF=cw8PCuk58oHPA-gQ@mail.gmail.com> <1423616F-F44D-47E5-8595-DE862DC04464@bsdimp.com> <546A34C8.6060004@freebsd.org> <CAG=rPVeEEuK874g6%2BfVpHa5J_4V%2BA%2BQNbB5bCpXiS86jZW_U3Q@mail.gmail.com> <546C8812.2070904@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 19 Nov 2014 16:07:46 +0400
"Alexander V. Chernikov" <melifaro@freebsd.org> 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"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20141119135651.789c6766>