dtrace tcps_rto bug?

[Mark Johnston]

On Tue, Oct 21, 2014 at 03:00:36PM +1100, grenville armitage wrote:
> 
> 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.

Right. I'm not sure what I was thinking when I wrote that line. :(

> 
> 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.)

I've committed the change as r273370. Thanks!

-Mark