Date: Mon, 18 Nov 2013 14:35:08 -0500 From: Steve Kiernan <stevek@juniper.net> To: Gleb Smirnoff <glebius@freebsd.org> Cc: freebsd-net@freebsd.org, luigi@freebsd.org, Marcel Moolenaar <marcel@freebsd.org>, zec@freebsd.org, Marcel Moolenaar <marcel@xcllnt.net> Subject: Re: [JNPR] Network stack as a module (RFC) Message-ID: <20131118143508.0253e663@stevek-ubuntu> In-Reply-To: <20131118164149.GV7577@glebius.int.ru> References: <CC6EF6B2.1917A%anshukla@juniper.net> <f1d8693fa83965f0d4a485a2db7e603b@novexsolutions.com> <50F868FF.5060506@networx.ch> <20131115165210.23f82578@stevek-ubuntu> <20131116084919.GF7577@glebius.int.ru> <1DAF9090-08DA-404B-B86B-57E5D124D70D@xcllnt.net> <20131118164149.GV7577@glebius.int.ru>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 18 Nov 2013 20:41:49 +0400 Gleb Smirnoff <glebius@freebsd.org> wrote: > Marcel, > > On Sun, Nov 17, 2013 at 10:10:15AM -0800, Marcel Moolenaar wrote: > M> > S> Add a NETSTACK option to facilitate separating network stack pieces from the > M> > S> rest of the OS core. This is the first step towards having the network stack > M> > S> as a module. > M> > > M> > You probably mean "having the network stack optional", since under module we > M> > usually mean loadable kernel module. > M> > M> Actually, we do mean module. At Juniper we have the FreeBSD stack > M> as a loadable module now. We also have the Juniper stack as a > M> loadable module. Depending on context, we can use the most > M> appropriate one. Yes, this implies that we also have a stable > M> interface between the NIC driver and the network stack itself. > M> We'll be contributing that as well... > M> > M> Note that assumptions in the finalization of setting up networking > M> limits the network stack from being loaded manually, not to mention > M> that unloading is an entirely different challenge. Nonetheless it's > M> very useful without all that and I think it will make it easier for > M> people to change the network stack or experiment with beta versions > M> this way. > > Have you measured the performance impact on the loadable stack? I > suppose many functions, that are now called directly, with loadable > stack will be called via functon pointers. No, only a small number of functions were needed to be methods in a netstack kobj in the current implementation that we have. And some of those may need to change, as they revolve around NFS exports. Currently, we have four (4) methods that are needed: socreate vfs_export vfs_setpublicfs vfs_stdcheckexp When one is not dealing with NFS exports, only the socreate method is of interest. It is called just before mac_socket_create() would be called in socreate(). See http://people.freebsd.org/~marcel/Juniper/netstack-v2.diff, which is the full patch set that had been previously sent out. Some things have changed a bit since then, but if you look for curnetstack usage in the patch, you should be able to see the places where netsack methods are called. -- Stephen J. Kiernan Juniper Networks, Inc. stevek_at_juniper.net
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20131118143508.0253e663>