svn commit: r288657 - head/sys/netinet6

Alexander V. Chernikov melifaro at freebsd.org
Wed Oct 7 07:35:24 UTC 2015


07.10.2015, 02:42, "Rui Paulo" <rpaulo at 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


More information about the svn-src-head mailing list