G'Day Darren,
On Mon, Jun 18, 2007 at 10:51:33AM -0700, [EMAIL PROTECTED] wrote:
> Brendan Gregg - Sun Microsystems wrote:
>
> >...
> >
> >Last night I dropped conn_t from the ip provider, and started recoding
> >it using ire_t and ill_t. The probes have also moved location, and many
> >are now near FW_HOOKS for physical events (before for inbound, after for
> >outbound). I'll post some suggested info structs when I see if ire_t and
> >ill_t are sensible to use (at the moment I'm not sure if I should be
> >trying to export ire_t for inbound packets - I'm doubting that it makes
> >sense).
> >
>
> The FW_HOOKS macros generally have sdt dtrace probes on
> either side of them, e.g.:
>
> DTRACE_PROBE4(ip4__forwarding__start,
> ill_t *, in_ill, ill_t *, out_ill, ipha_t *, ipha, mblk_t *,
> mp);
>
> FW_HOOKS(ipst->ips_ip4_forwarding_event,
> ipst->ips_ipv4firewall_forwarding,
> in_ill, out_ill, ipha, mp, mp, ipst);
>
> DTRACE_PROBE1(ip4__forwarding__end, mblk_t *, mp);
>
> If your probes are getting close to where FW_HOOKS appears,
> is there some merit in replacing some of these sdt probes
> with probes from the provider you're working on?
They were indeed getting close - at one point I had this in ip_wput_ire(),
DTRACE_PROBE4(ip4__physical__out__start, ill_t *, NULL,
ill_t *, ire->ire_ipif->ipif_ill, ipha_t *, ipha,
mblk_t *, mp);
FW_HOOKS(ipst->ips_ip4_physical_out_event,
ipst->ips_ipv4firewall_physical_out,
NULL, ire->ire_ipif->ipif_ill, ipha, mp, mp, ipst);
DTRACE_PROBE1(ip4__physical__out__end, mblk_t *, mp);
if (mp == NULL)
goto release_ire_and_ill;
/*
* DTrace this as ip:::send and ipv4:::send.
*/
DTRACE_IP2(send, mblk_t *, mp, void_ip_t *, ipha);
DTRACE_IPV4_5(send, mblk_t *, mp, void_ip_t *, ipha, ipha_t *,
ipha, int, 0, ill_t *, ire->ire_ipif->ipif_ill);
mp->b_prev = SET_BPREV_FLAG(IPP_LOCAL_OUT);
DTRACE_PROBE2(ip__xmit__1, mblk_t *, mp, ire_t *, ire);
pktxmit_state = ip_xmit_v4(mp, ire, NULL, B_TRUE);
which has three generations of DTrace probes in one place!
... but not anymore - those ip:::send probes are now in ip_xmit_v4()...
> Although this might only make sense of there is complete
> coversion of all the sdt's into the new thing.
I did spend some time thinking about what could be done, as it the
FW_HOOKS have already instrumeted packet code-paths at a fairly
low level (I wish they existed in Solaris 10 3/05 - my fbt based
scripts would have been much easier to write).
The IP providers must be a completely stable interface - and can't export
mblk_t, ill_t, etc directly; however to do so with SDT probes is great for
debugging, and the FW_HOOKS probes could even have more arguments added
(ire_t, ...), and more probes of a similar style created.
I think the FW_HOOKS SDT probes would be part of (and currently lead the
way for) a debugging or code-path-latency provider.
There are also a few places where FW_HOOKS SDT and the IP provider probes
diverge - eg, ip_wput_frag_mdt().
> ...I'm sure that there is such a thing as too many dtrace
> probe points :)
These are near zero overhead when not enabled (some nops plus some movs to
set registers); although their existance may affect how the compiler
optimizes code (especially if there were loads of probes). In any case,
the CPU overhead is going to need to be measured.
It might be safer to say that there shouldn't be too many stable provider
probes in the code. Unstable probes such as those SDT ones can be dropped
if their overhead proves to be a problem, however probes can't easily be
dropped from a stable and committed provider.
cheers,
Brendan
--
Brendan
[CA, USA]
_______________________________________________
networking-discuss mailing list
networking-discuss@opensolaris.org
