[dtrace-discuss] Info about Dtrace Network Provider
Hi, The Dtrace Network Provider page has some nice features. When is this being planned to be integrated into Nevada? I wanted to try it out. Where can I get access to the bfu/iso images? Regards, Kini -- Sun Microsystems - India Engineering Centre http://blogs.sun.com/jkini ___ dtrace-discuss mailing list dtrace-discuss@opensolaris.org
Re: [dtrace-discuss] [networking-discuss] DTrace IP provider, step 1
G'Day,
Sorry - I missed a change in that document; I've attached a newer copy which
has the following minor update:
illinfo_t renamed to ifinfo_t
Brendan
On Wed, Apr 30, 2008 at 03:15:07PM -0700, Brendan Gregg - Sun Microsystems
wrote:
> G'Day All,
>
> I've attached an updated draft PSARC document for the IP provider. Please
> comment by May 6th, which is when we plan to file and close this case.
>
> The only change to this draft was the addition of two new string members:
>
> string ipv4_protostr; /* next level protocol, as a string */
> string ipv6_nextstr; /* next header protocol, as a string */
>
> cheers,
>
> Brendan
[...]
--
Brendan
[CA, USA]
A. INTRODUCTION
This case adds a DTrace 'ip' provider with probes for send and receive for
both IPv4 and IPv6 protocols. This is intended for use by customers for
network observability and troubleshooting, and is the first component of
a suite of planned providers for the network stack. These providers have
previously been discussed on public mailing lists: see section D for
references.
B. DESCRIPTION
This will introduce the following probes for the 'ip' provider:
ip:::send
ip:::receive
The arguments to these probes are:
args[0] pktinfo_t * packet info
args[1] csinfo_t * connection state info
args[2] ipinfo_t * generic IP info
args[3] ifinfo_t * interface info
args[4] ipv4info_t *IPv4 header
args[5] ipv6info_t *IPv6 header
The order and content has been chosen for consistency with other planned
network providers, and to also leave room to accommodate future
enhancements to the network stack.
The arguments contain:
/*
* pktinfo is where packet ID info can be made available for deeper
* analysis if packet IDs become supported by the kernel in the future.
* The pkt_addr member is currently always NULL.
*/
typedef struct pktinfo {
uintptr_t pkt_addr;
} pktinfo_t;
/*
* csinfo is where connection state info can be made available if
* connection IDs become supported by the kernel in the future.
* The cs_addr member is currently always NULL.
*/
typedef struct csinfo {
uintptr_t cs_addr;
} csinfo_t;
/*
* ipinfo contains common IP info for both IPv4 and IPv6.
*/
typedef struct ipinfo {
uint8_t ip_ver; /* IP version (4, 6) */
uint16_t ip_plength;/* payload length */
string ip_saddr;/* source address */
string ip_daddr;/* destination address */
} ipinfo_t;
/*
* ifinfo contains network interface info.
*/
typedef struct ifinfo {
string if_name; /* interface name */
int8_t if_local;/* is delivered locally */
netstackid_t if_ipstack;/* ipstack ID */
uintptr_t if_addr; /* pointer to raw ill_t */
} ifinfo_t;
/*
* ipv4info is a translated version of the IPv4 header (with raw pointer).
* These values are NULL if the packet is not IPv4.
*/
typedef struct ipv4info {
uint8_t ipv4_ver; /* IP version (4) */
uint8_t ipv4_ihl; /* header length, bytes */
uint8_t ipv4_tos; /* type of service field */
uint16_t ipv4_length; /* length (header + payload) */
uint16_t ipv4_ident;/* identification */
uint8_t ipv4_flags; /* IP flags */
uint16_t ipv4_offset; /* fragment offset */
uint8_t ipv4_ttl; /* time to live */
uint8_t ipv4_protocol; /* next level protocol */
string ipv4_protostr; /* next level protocol, as a string */
uint16_t ipv4_checksum; /* header checksum */
ipaddr_t ipv4_src; /* source address */
ipaddr_t ipv4_dst; /* destination address */
string ipv4_saddr; /* source address, string */
string ipv4_daddr; /* destination address, string */
ipha_t *ipv4_hdr; /* pointer to raw header */
} ipv4info_t;
/*
* ipv6info is a translated version of the IPv6 header (with raw pointer).
* These values are NULL if the packet is not IPv6.
*/
typedef struct ipv6info {
uint8_t ipv6_ver; /* IP version (6) */
uint8_t ipv6_tclass;/* traffic class */
uint32_t ipv6_flow; /* flow label */
uint16_t ipv6_plen; /* payload length */
uint8_t ipv6_nexthdr; /* next header protocol */
string ipv6_nextstr;/* next header protocol, as a string */
uint8_t ipv6_hlim; /* hop limit */
in6_addr_t *ipv6_src; /* source address */
in6_addr_t *ipv6_dst; /* destination address */
str
Re: [dtrace-discuss] Help pid provider follow child processes
On Wed, 2008-04-30 at 17:51 +0200, [EMAIL PROTECTED] wrote:
> > Well, if you're really talking about re-inserting probes into a
> > completely new image (after the exec)
> > than I consider DTrace to be doing exactly the right thing -- these
> > are brand new probes so they have to be reinserted.
>
> I am dealing with same problem as Bayard trying to trace child processes.
> >From Roman's answer I do not exactly know if it is possible or not.
It is possible via the system action that would reinsert the probes
into the brand new PID.
> What do you
> mean with "DTrace to be doing exactly the right thing -- these are brand
> new
> probes so they have to be reinserted."?? I've tried to trace my test
> program which spawns
> child and I really wasn't able to see any trace output for that child from
> pid provider.
That's why I asked my question -- I can agree that if the process simply
forks and does NOT do an exec DTrace can be expected (although not
required) to keep the probes around. Once exec is done -- all bets are
off anyway. You have to reinsert the probes. Regardless of whether
you do it manually (via system("dtrace...");) or you have your
dynamic PID provider. Works needs to be done. Unlike with pure forks
where in fact, work is done to *remove* probes from the newborn child.
> However I really do not know if it is technically possible to create "dynamic
> pid provider" :-)
Well, start hacking, then ;-)
Thanks,
Roman.
___
dtrace-discuss mailing list
dtrace-discuss@opensolaris.org
Re: [dtrace-discuss] [networking-discuss] DTrace IP provider, step 1
G'Day All,
I've attached an updated draft PSARC document for the IP provider. Please
comment by May 6th, which is when we plan to file and close this case.
The only change to this draft was the addition of two new string members:
string ipv4_protostr; /* next level protocol, as a string */
string ipv6_nextstr; /* next header protocol, as a string */
cheers,
Brendan
On Mon, Dec 31, 2007 at 04:41:41PM -0800, Brendan Gregg - Sun Microsystems
wrote:
> G'Day All,
>
> The DTrace ip provider is almost ready for putback into Solaris Nevada.
> Recapping, the following steps were performed in preperation for this:
[...]
> On Thu, Dec 20, 2007 at 02:41:32PM -0800, Brendan Gregg - Sun Microsystems
> wrote:
> > G'Day All,
> >
> > I'm putting together a PSARC case to begin integration of the DTrace network
> > providers. I've drawn up a rough plan which splits this project into over a
> > dozen smaller steps, as documented on the network provider page:
> >
> > http://www.opensolaris.org/os/community/dtrace/NetworkProvider#Plan
> >
> > Below is a draft PSARC document for task 1, IP provider send/receive probes.
> > I'm looking to integrate this in the coming weeks, and then to move straight
> > onto tasks 2 and 3 - TCP and UDP providers.
> [...]
>
> --
> Brendan
> [CA, USA]
--
Brendan
[CA, USA]
A. INTRODUCTION
This case adds a DTrace 'ip' provider with probes for send and receive for
both IPv4 and IPv6 protocols. This is intended for use by customers for
network observability and troubleshooting, and is the first component of
a suite of planned providers for the network stack. These providers have
previously been discussed on public mailing lists: see section D for
references.
B. DESCRIPTION
This will introduce the following probes for the 'ip' provider:
ip:::send
ip:::receive
The arguments to these probes are:
args[0] pktinfo_t * packet info
args[1] csinfo_t * connection state info
args[2] ipinfo_t * generic IP info
args[3] illinfo_t * interface info
args[4] ipv4info_t *IPv4 header
args[5] ipv6info_t *IPv6 header
The order and content has been chosen for consistency with other planned
network providers, and to also leave room to accommodate future
enhancements to the network stack.
The arguments contain:
/*
* pktinfo is where packet ID info can be made available for deeper
* analysis if packet IDs become supported by the kernel in the future.
* The pkt_addr member is currently always NULL.
*/
typedef struct pktinfo {
uintptr_t pkt_addr;
} pktinfo_t;
/*
* csinfo is where connection state info can be made available if
* connection IDs become supported by the kernel in the future.
* The cs_addr member is currently always NULL.
*/
typedef struct csinfo {
uintptr_t cs_addr;
} csinfo_t;
/*
* ipinfo contains common IP info for both IPv4 and IPv6.
*/
typedef struct ipinfo {
uint8_t ip_ver; /* IP version (4, 6) */
uint16_t ip_plength;/* payload length */
string ip_saddr;/* source address */
string ip_daddr;/* destination address */
} ipinfo_t;
/*
* illinfo contains IP Lower Layer info.
*/
typedef struct illinfo {
string ill_name;/* interface name */
int8_t ill_local; /* is local */
netstackid_t ill_ipstack; /* ipstack ID */
uintptr_t ill_addr; /* pointer to raw ill_t */
} illinfo_t;
/*
* ipv4info is a translated version of the IPv4 header (with raw pointer).
* These values are NULL if the packet is not IPv4.
*/
typedef struct ipv4info {
uint8_t ipv4_ver; /* IP version (4) */
uint8_t ipv4_ihl; /* header length, bytes */
uint8_t ipv4_tos; /* type of service field */
uint16_t ipv4_length; /* length (header + payload) */
uint16_t ipv4_ident;/* identification */
uint8_t ipv4_flags; /* IP flags */
uint16_t ipv4_offset; /* fragment offset */
uint8_t ipv4_ttl; /* time to live */
uint8_t ipv4_protocol; /* next level protocol */
string ipv4_protostr; /* next level protocol, as a string */
uint16_t ipv4_checksum; /* header checksum */
ipaddr_t ipv4_src; /* source address */
ipaddr_t ipv4_dst; /* destination address */
string ipv4_saddr; /* source address, string */
string ipv4_daddr; /* destination address, string */
ipha_t *ipv4_hdr; /* pointer to raw header */
} ipv4info_t;
/*
* ipv6info is a translated version of the IPv6 header (with raw pointer).
* These values are NULL if the
Re: [dtrace-discuss] Help pid provider follow child processes
>>
>> On 16 Apr 2008, at 23:32, Roman Shaposhnik wrote:
>>
>>> On Mon, 2008-04-14 at 23:03 +0100, Bayard Bell wrote:
I've just recently started working with DTrace and one of the first
issues I've run across is the difficulty in following child
processes
when instrumenting user space.
>>>
>>> Are trying to survive fork/exec or just a single process forking its
>>> image?
>>
>> I'm looking to re-initialise the same set of probes under the pid
>> provider against child processes subsequently created by fork/exec.
> Well, if you're really talking about re-inserting probes into a
> completely new image (after the exec)
> than I consider DTrace to be doing exactly the right thing -- these
> are brand new probes so they have to be reinserted.
I am dealing with same problem as Bayard trying to trace child processes.
>From Roman's answer I do not exactly know if it is possible or not. What do
>you
mean with "DTrace to be doing exactly the right thing -- these are brand
new
probes so they have to be reinserted."?? I've tried to trace my test
program which spawns
child and I really wasn't able to see any trace output for that child from pid
provider.
>From my point of view as the name of probe "pidPID" has to be specified
statically I can see no way how to trace child processes (as we don't know
PID when starting the script) without destructive hacks like ones described in
this thread
http://mail.opensolaris.org/pipermail/dtrace-discuss/2007-April/003733.html.
I consider the way how pid provider works a big drawback of dtrace for
user-land
debugging/tracing. I often need to debug complex multi-process
application/service
where I just can't do something like "dtrace -c app". Cosider a daemon - after
start,
daemons often spawns new process, daemonize child with setsid etc. and letting
parent process die. Yes I can look for PID after that and run new dtrace
session but
then I will lose lot of interesting information (like deamon initialization).
Other good examples are short-lived processes spawned by master process - you
really do need to know what's happening inside them. I would like to see
something
like shortlived.d script from DTraceToolkit but with capability to trace
function calls not
only time spent in them.
Other thing that would be possible if there wouldn't be a need to specify PID
statically
within pid provider would be nice library tracing. Wouldn't be nice if
following would be possible?:
:mylibrary.so:myfunction:entry {
printf("myfunction: parameter x %d was supplied by program %s with PID
%d\n",arg[0],execname,pid);
}
With this I could as questions like:
What programs are using this library function?
What program uses this library function most frequently?
What is the common pattern that this function is receiving?
However I really do not know if it is technically possible to create "dynamic
pid provider" :-)
J.
___
dtrace-discuss mailing list
dtrace-discuss@opensolaris.org
Re: [dtrace-discuss] disp_getwork question
disp_getwork() is a kernel function that gets called from the idle loop (dispatcher - go get work, meaning find me a runnable thread). (usermode) simply means that the CPU(s) were running in usermode, not kernel mode during the profile, and lockstat has not visibility into what user functions where running during the sample. The best it can do it tell you the cpus(s) were not running in the kernel. Try; #dtrace -n 'profile-997hz / arg0 != 0 && curthread->t_pri != -1 / @[func(arg0)] = count() }' for a kernel profile that filters out the idle loop. /jim Jianhua Yang wrote: > Hello, > > I collected lockstat statistics when CPU idle is less 10, see below: > > Profiling interrupt: 120600 events in 5.038 seconds (23940 events/sec) > > Count indv cuml rcnt nsec CPU+PILCaller > --- > 3430 3% 3% 0.00 1225 cpu[3]+11 disp_getwork > 3378 3% 6% 0.00 1429 cpu[512]+11disp_getwork > 3319 3% 8% 0.00 1254 cpu[515]+11disp_getwork > > 1407 1% 61% 0.00 1238 cpu[11](usermode) > 972 1% 62% 0.00 2664 cpu[18](usermode) > 953 1% 63% 0.00 833 cpu[528] (usermode) > > question: > 1. what is disp_getwork ?I guess this function comes from "shced" > ? if trace "sched" procss functions, > say 5 seconds, what is overhead of performance? > 2. caller = (usermode), what is usermode mean here ? why did it not > trace out the functions ? > > Thanks, > > James Yang > --- > > This e-mail may contain confidential and/or privileged information. If you > are not the intended recipient (or have received this e-mail in error) > please notify the sender immediately and destroy this e-mail. Any > unauthorized copying, disclosure or distribution of the material in this > e-mail is strictly forbidden. > > ___ > dtrace-discuss mailing list > dtrace-discuss@opensolaris.org > ___ dtrace-discuss mailing list dtrace-discuss@opensolaris.org
[dtrace-discuss] disp_getwork question
Hello, I collected lockstat statistics when CPU idle is less 10, see below: Profiling interrupt: 120600 events in 5.038 seconds (23940 events/sec) Count indv cuml rcnt nsec CPU+PILCaller --- 3430 3% 3% 0.00 1225 cpu[3]+11 disp_getwork 3378 3% 6% 0.00 1429 cpu[512]+11disp_getwork 3319 3% 8% 0.00 1254 cpu[515]+11disp_getwork 1407 1% 61% 0.00 1238 cpu[11](usermode) 972 1% 62% 0.00 2664 cpu[18](usermode) 953 1% 63% 0.00 833 cpu[528] (usermode) question: 1. what is disp_getwork ?I guess this function comes from "shced" ? if trace "sched" procss functions, say 5 seconds, what is overhead of performance? 2. caller = (usermode), what is usermode mean here ? why did it not trace out the functions ? Thanks, James Yang --- This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. ___ dtrace-discuss mailing list dtrace-discuss@opensolaris.org
