dtrace tcps_rto bug?

[grenville armitage]

I'm curious about dtrace's args[3]->tcps_rto calculation.

Right now /usr/src/cddl/lib/libdtrace/tcp.d defines tcps_rto as:

	typedef struct tcpsinfo {
		[..]
			uint32_t tcps_rto;              /* round-trip timeout, msec */
		[..]
	} tcpsinfo_t;

And then later derives tcps_rto from p->t_rxtcur like so:

	tcps_rto =     p == NULL ? -1  : p->t_rxtcur / 1000;  /* XXX */

I doubt this is right.

t_rxtcur is the kernel's notion of RTO in ticks (as per netinet/tcp_var.h), so for a kernel where HZ=1000 the preceding calculation would result tcps_rto being the RTO in seconds (not milliseconds, as stated in the struct tcpsinfo definition). And for kernels where HZ != 1000, all bets are off.

Inside a dtrace .d file we can use "`hz" to represent the running kernel's current tick rate (kern.hz), so I believe the correct expression for tcps_rto would be:

	tcps_rto =     p == NULL ? -1  : (p->t_rxtcur * 1000) / `hz;

(I've run a few simple tests, and this change seems to produce plausible RTO values in milliseconds when args[3]->tcps_rto is read from inside a tcp:::send probe.)

cheers,
gja