DTrace IP Provider [PSARC/2008/302 FastTrack timeout 05/07/2008]

[Brendan Gregg - Sun Microsystems]

G'Day Erik,

On Sun, May 11, 2008 at 09:34:20AM -0700, Erik Nordmark wrote:
> Adam,
> 
> Overall this looks good. One nit though.
> 
> >/*
> > * 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;
> 
> I don't think "payload length" has a natural definition when trying to 
> look at what IP actually carries because of the IPv6 extension headers.
> For instance, for a 100 byte IPv6 packet with a 8 byte hop-by-hop 
> options header, a fragment header, and a TCP header, what is the payload 
> length?
> The IPv6 header field for payload length is just 40 less than the size 
> of the IPv6 packet. But the payload that IP delivers to TCP is less all 
> the extension headers. And some might think that "payload" refers to the 
> TCP payload.
> Thus I think it would be more clear to have the IP provider expose the 
> IP packet length instead of payload length.

ipinfo_t is to provide basic IP details across all protocols: TCP, UDP,
ICMP, etc - which isn't obvious from this case alone.  We can't assume
that a complete IP header will be available at these times - it may be as
an implementation artifact but this isn't stable.  What we can provide is
an "IP payload length at time of tracing", and document that this is
provided for convenience.  The IP provider ipv4info_t and ipv6info_t
structs are to provide the best understanding of what IP really does.

The ipv4info_t and ipv6info_t structs are based on the protocol fields; but
can include additional members if they are stable and useful.  This is the
best location for exposing the actual IP packet length, as these structs are
only used by the IP provider when the headers should be available.  IPv4
does have this member (ipv4_length), but IPv6 does not (it would be
calculated using ipv6_plen + IPV6_HDR_LEN).

Exporting the packet length easily from the IP provider would indeed be
useful and has a clear definition that should reduce confusion.  We can
add this to the ipv6info_t as ipv6_length, with the ipv4 companion as 
ipv4_length.  How does that sound?

cheers,

Brendan

-- 
Brendan
[CA, USA]