dtrace discuss - Sep 2006 - [Fwd: [networking-discuss] Re: DTrace Network Provider]

Forwarding this to dtrace-discuss at opensolaris.org

-------- Original Message --------

Date: Tue, 19 Sep 2006 10:57:57 -0700
From: Sangeeta Misra <Sangeeta.Misra at sun.com>
Subject: [networking-discuss] Re: [dtrace-discuss] DTrace Network Provider
Sender: networking-discuss-bounces at opensolaris.org
To: dtrace-discuss at opensolaris.org
Cc: networking-discuss at opensolaris.org


Brendan Gregg - Sun Microsystems wrote:
> G''Day Folks,
>
> I''ve just created a website to flesh out ideas for a DTrace
> Network Provider.
> Let us know what you think.
>
> http://www.opensolaris.org/os/community/dtrace/NetworkProvider/
Brendan,

Given a Solaris box that is configured to be a forwarder, I want to use
the above to find out how long it takes a packet to be forwarded out
into the wire from the time its received (this would mean time spent in
IP and in network driver code)

Will the DTrace Network Provider be able to provide this info?

Sangeeta

_______________________________________________
networking-discuss mailing list
networking-discuss at opensolaris.org

G''Day Sangeeta,

On Tue, 19 Sep 2006, Sangeeta Misra wrote:
> Forwarding this to dtrace-discuss at opensolaris.org
>
> -------- Original Message --------
>
> Date: Tue, 19 Sep 2006 10:57:57 -0700
> From: Sangeeta Misra <Sangeeta.Misra at sun.com>
> Subject: [networking-discuss] Re: [dtrace-discuss] DTrace Network Provider
> Sender: networking-discuss-bounces at opensolaris.org
> To: dtrace-discuss at opensolaris.org
> Cc: networking-discuss at opensolaris.org
>
>
> Brendan Gregg - Sun Microsystems wrote:
> > G''Day Folks,
> >
> > I''ve just created a website to flesh out ideas for a DTrace
> > Network Provider.
> > Let us know what you think.
> >
> > http://www.opensolaris.org/os/community/dtrace/NetworkProvider/
>
> Brendan,
>
> Given a Solaris box that is configured to be a forwarder, I want to use
> the above to find out how long it takes a packet to be forwarded out
> into the wire from the time its received (this would mean time spent in
> IP and in network driver code)
>
> Will the DTrace Network Provider be able to provide this info?
To associate one ethernet received event to an ethernet sent event
won''t
be easy, but I can understand the usefullness of this. There are however
more importent needs that the Network Provider design already meets;

Consider the DTrace io provider. It would be nice to see how long it takes
from an application requesting a read to when the disk actually reads -
time spent in the file system caches, VFS, the disk driver, etc.

The io provider currently doesn''t do this - and yet the io provider has
been a saviour for observability. Customers have been using the io
provider to measure event sizes, filenames, and other straightforward
details.

I personally want to measure time spent from application reads through to
disk reads, broken down by kernel layer; but this was after solving dozens
of problems.

Brendan

Brendan Gregg wrote:
>>Brendan,
>>
>>Given a Solaris box that is configured to be a forwarder, I want to use
>>the above to find out how long it takes a packet to be forwarded out
>>into the wire from the time its received (this would mean time spent in
>>IP and in network driver code)
>>
>>Will the DTrace Network Provider be able to provide this info?
> 
> 
> To associate one ethernet received event to an ethernet sent event
won''t
> be easy, but I can understand the usefullness of this.
OK
> There are however
> more importent needs that the Network Provider design already meets;
> 
"More important" is a subjective comment.  I am sure identifying 
bottlenecks/latencies in host and forwarding path is important to us in 
Networking and using DTrace Network Provider to get this information 
would be very handy.
> Consider the DTrace io provider. It would be nice to see how long it takes
> from an application requesting a read to when the disk actually reads -
> time spent in the file system caches, VFS, the disk driver, etc.
> 
> The io provider currently doesn''t do this - and yet the io
provider has
> been a saviour for observability.
> Customers have been using the io
> provider to measure event sizes, filenames, and other straightforward
> details.
> 
OK(though I am not sure how that addresses my question).
> I personally want to measure time spent from application reads through to
> disk reads, broken down by kernel layer; but this was after solving dozens
> of problems.
Are you saying that DTrace Network Provider is not the right tool for 
this feature, because that is not what Dtrace is intended for (and thus 
implementing this would result in a bulky implementation). If so, can 
you suggest a more effcient alternative way to get this info?

Or are you stating that you wont consider implementing it simply because 
you dont think it to be a important feature?

Sangeeta

G''Day Sangeeta,

On Wed, 20 Sep 2006, Sangeeta Misra wrote:
> Brendan Gregg wrote:
[...]
> > There are however
> > more importent needs that the Network Provider design already meets;
> >
> "More important" is a subjective comment.  I am sure identifying
> bottlenecks/latencies in host and forwarding path is important to us in
> Networking and using DTrace Network Provider to get this information
> would be very handy.
>
> > Consider the DTrace io provider. It would be nice to see how long it
takes
> > from an application requesting a read to when the disk actually reads
-
> > time spent in the file system caches, VFS, the disk driver, etc.
> >
> > The io provider currently doesn''t do this - and yet the io
provider has
> > been a saviour for observability.
> > Customers have been using the io
> > provider to measure event sizes, filenames, and other straightforward
> > details.
> >
> OK(though I am not sure how that addresses my question).
Sigh. This is exactly equivalent to what you are asking.
> > I personally want to measure time spent from application reads through
to
> > disk reads, broken down by kernel layer; but this was after solving
dozens
> > of problems.
>
> Are you saying that DTrace Network Provider is not the right tool for
> this feature, because that is not what Dtrace is intended for (and thus
> implementing this would result in a bulky implementation). If so, can
> you suggest a more effcient alternative way to get this info?
If the network engineers want to trace code path for their own needs,
then do so with fbt and add some sdt as needed. But don''t assume that
customers care most about seeing code path, or have read the 50,000+
lines that make up tcp.c and ip.c.
> Or are you stating that you wont consider implementing it simply because
> you dont think it to be a important feature?
Go back and reread what I said.

Brendan