[dtrace-discuss] [networking-discuss] Re: DTrace Network Providers, take 2

[Brendan Gregg - Sun Microsystems]

On Thu, Jun 21, 2007 at 11:49:24AM +0100, Jeremy Harris wrote:
> Hi Brendan,
> 
> Brendan Gregg - Sun Microsystems wrote:
> >On Wed, Jun 20, 2007 at 09:53:44PM +0100, Jeremy Harris wrote:
> >>Brendan Gregg - Sun Microsystems wrote:
> >>>  ID   PROVIDER            MODULE                          FUNCTION NAME
> >>[...]
> >>>11668       ipv4                ip                  tcp_lsosend_data send
> >>>11669       ipv4                ip                tcp_multisend_data send
> >>Aren't these more implementation artifacts than things suitable
> >>for exposure in a stable provider?
> [...]
> >If you meant that LSO and MDT are implementation details, then sure,
> >their activity is tied to implementation, and the IP packets that they
> >generate will be observable by the stable IP provider in a 
> >non-implementation
> >specific way (send/receive probes, not lso-send/mdt-send/etc).
> 
> This is what I meant, yes.
> So, what stability level will these probes have?

As a new interface, I'd write the DTrace stability table as,

                |  Name            Data            Class
   -------------+-------------------------------------------
   Provider     |  Evolving        Evolving        Common
   Module       |  Private         Private         Unknown
   Function     |  Private         Private         Unknown
   Name         |  Evolving        Evolving        Common
   Arguments    |  Unstable        Unstable        Common

with Arguments becomming "Evolving" in the near future.

The aim of the provider is to be a stable end user interface, with the
send/receive probes tracing activity between IP and the device driver
framework, or itself (loopback).

So for send probes - whatever IP sends down, is traced. For receive probes,
whatever IP receives, is traced.

For MDT, it should be able to trace the individual IP packets as ip:::send,
similar to what sdt::tcp_multisend:ip4-physical-out-start does when hooks
are on.

For LSO, what IP sends down can be 64 Kbyte packets - which is what the IP
provider will trace as a 64 Kbyte ip:::send. This is in line with the role
of the IP provider - to trace what was sent and received to the device
driver layers. Is 64 Kbyte sends confusing enough that it should really be
called ip:::lso-send? ... I don't think so.

What about future hypothetical NIC performance feature, that accepts 
packets in some other manner that is much stranger than LSO? That may
indeed be a case for new probe, ip:::mumblefoo-send, or whatever.

Brendan

-- 
Brendan
[CA, USA]