Date: Wed, 07 Oct 2015 10:35:06 +0300 From: Alexander V. Chernikov <melifaro@freebsd.org> To: Rui Paulo <rpaulo@me.com>, "src-committers@freebsd.org" <src-committers@freebsd.org>, "svn-src-all@freebsd.org" <svn-src-all@freebsd.org>, "svn-src-head@freebsd.org" <svn-src-head@freebsd.org> Subject: Re: svn commit: r288657 - head/sys/netinet6 Message-ID: <91311444203306@web12g.yandex.ru> In-Reply-To: <1444174917.6210.43.camel@me.com> References: <201510040821.t948LGH7000421@repo.freebsd.org> <1444174917.6210.43.camel@me.com>
next in thread | previous in thread | raw e-mail | index | archive | help
07.10.2015, 02:42, "Rui Paulo" <rpaulo@me.com>: > On Sun, 2015-10-04 at 08:21 +0000, Alexander V. Chernikov wrote: >> šAuthor: melifaro >> šDate: Sun Oct 4 08:21:15 2015 >> šNew Revision: 288657 >> šURL: https://svnweb.freebsd.org/changeset/base/288657 >> >> šLog: >> šššAdd __noinline attribute to several functions to ease dtrace >> šinstrumentation > > What instrumentation? Is there a DTrace script in userland that uses Well, given that ND state machine is a bit complex, it is nice to have some sort of easy-to-turn-on hooks to monitor its state (I suspect this is true not only for me, but to other people hacking IPv6 code). dtrace and its fbt provider does the great thing of exporting most of needed functions. However, due to inlining, not all calls can be hooked. > these functions? If not, this should not have been committed as you > just made the code slower. This is one of those changes that should be I do understand that in general telling compiler not to inline functions might slow things down. However, all functions except nd6_resolve_slow are not used in data path, so, well, losing fraction of percent is not a big deal for control function. Do you have different view on that? nd6_resolve_slow() is currently called when fast path processing failed and we have to acquire lle write lock and so on. (But yes, right now it could be called on per-packet basis in STALE/PROBE state, (which is going to be changed in D3780)). What could be done better is probably having some kind of __dtrace_inline define under KDTRACE_HOOKS kernel options. Does this look better to you or you have some different approach in mind (like explicitly defining dtrace probes or maybe something different) ? > kept in your own repository. > > -- > Rui Paulo
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?91311444203306>