On Wed, Sep 27, 2006 at 12:11:38PM -0700, Brendan Gregg - Sun Microsystems wrote: > On Mon, Sep 25, 2006 at 04:00:02PM -0700, [EMAIL PROTECTED] wrote: > > The difference between using fbt and being able to follow a packet > > is when a packet is put on a queue, the fbt path is terminated, > > even though the packet still has places to go and I/O ports to see. > > > > If the networking dtrace provider doesn't deliver the capability > > to trace a packet through the kernel then it is not delivering a > > key feature that is needed by many people. > > Noone is saying that the provider will never do this. If you are saying > that this feature is important to you, then sure - I understand. > And if many people means many engineers (which in turn helps them > achieve cool things), then I understand that too.
The fbt provider allows you to probe function calls/returns. It still requires that the scripter thread together the actual function calls into a trace of call flow -- as far as the kernel side of DTrace is concerned the fbt probe firings are discrete events. The same should apply to a network provider, but I'm afraid it won't. The thing that makes it easy to thread function calls/returns is that they all happen in the same thread of execution and in sequence. The same is not necessarily true of "packets." There's multicast, and SOCK_RAW, fragmentation, etc... Also, do you want to trace flows all the way from the link layer through applications (e.g., NFS, Apache)? That seems even more daunting. How do you thread receipt of fragmented packets into a nice call flow- style of report? If it takes associative arrays to do it then it will be expensive. In order to rely on thread locals one might have to be able to rely on packets being processed all in one thread -- an assumption that we shouldn't want to make, even if it were true. But I somehow doubt that would be the primary use of a network provider. Nico -- _______________________________________________ networking-discuss mailing list [email protected]
