Re: [PATCH] (Updated) trace tcp connections parameters

[Josh Stone <jistone at redhat dot com>]

On 10/06/2009 12:12 PM, David J. Wilder wrote:
> This script (tcp_trace) can be used to trace tcp connection parameters and
> state changes.  This work was original inspired by Stephen Hemminger's
> TCP cwnd snooper (net/ipv4/tcp_probe.c). Tcp_trace is a helpful tool
> for troubleshooting connection performance issues.
> 
> In this updated patch I address Josh Stone's review comments:
> http://sources.redhat.com/ml/systemtap/2009-q3/msg00897.html

Thanks, you've addressed those points nicely.

> - I re-wrote print_packet_info() to support variable length output
> records.  However in doing so I may have added string copies against
> Josh's advice :(

That wasn't a critical point, just a suggestion to avoid our sub-optimal
code generation.  But anyway, you could change this:

  ..
  txq_prnt = txq_flg ? sprintf("%8d",txq[key]) : empty
  rxq_prnt = rxq_flg ? sprintf("%8d",rxq[key]) : empty
  ...
  printf("...%s%s...\n", ..., txq_prnt, rxq_prnt, ...)

into this:

  ...
  if (txq_flg) printf("%8d", txq[key])
  if (rxq_flg) printf("%8d", rxq[key])
  ...
  printf("\n")

So you can just print each piece as it comes, with no string temps.  The
printfs go into a percpu buffer that's flushed at the end of the probe,
so even writing it piecemeal should still come out atomically.

> Note: Rules can be used to limit tracing to a single socket
> or allow many sockets to be traced at one time. Memory consumed
> by the tracer will increase with the number of connections
> being traced.

That's not really true -- we allocate fixed memory for the maps at the
beginning of the script, so actually a single connection and many
connections will still have the same memory consumption on our end.

But that does remind me, when a connection is finished you should
probably delete the corresponding key from all the maps.  Otherwise, the
script will die as soon as it sees more than MAXMAPENTRIES connections
(default 2048).  You'll still have that limit concurrently, but you
don't want to accumulate data for old connections.  I left this running
in the background on my laptop, and it died after about an hour due to
overflowing the maps.

Thanks,

Josh