Re: Tracing packet behaviour inside the kernel

[Darren Reed <darrenr%netbsd.org@localhost>]

Greg Troxel wrote:
> No, I am really looking for packet data, but perhaps packet metadata a
> la DLT_IEEE802_11_RADIO.  As a first step, I want the data source
> labeled, so I can know if I have queueing delays or not.  The point of
> tapping at tx complete is that you can find out how many retries were
> used and what the actual rate for that packet was (sometimes an 802.11
> interface will drop back to 1 Mb/s after failing to get an ack at the
> chosen rate), or if no ack was received.  I wanted this data to compute
> the ETX metric
> 
>   http://pdos.csail.mit.edu/papers/grid:mobicom03/paper.pdf
>   http://pdos.csail.mit.edu/decouto/abstract.html
> 
> which is otherwise a bit hard to get.  I was relatively unconcerned
> about processing overhead and how the software was functioning etc.  In
> my case I added a new 'tracerecord' DLT that had a metadata record for
> each packet with the at-tx-complete stats.

That sounds like a very specialised piece of instrumentation,
which BPF (as a generic packet capture feature) isn't really
well suited to be (I think.)

*but* I do think dtrace would help here... for example, you can
measure the time between a packet entering ip_output and it being
free'd or entering the send routine for a NIC lower down.

I can't see anything in your description that would preclude a
tool like dtrace from being used...

Darren