Re: [net-next] tcp: do tcp_mstamp_refresh before retransmits on TSQ handler

On Sun, 2017-10-22 at 20:40 -0700, Eric Dumazet wrote:

On Mon, 2017-10-23 at 12:26 +0900, Koichiro Den wrote:

quoted

Now I wonder this is more of a theoretical one rather than a patch to fix
one
specific bug.

Note that I said that your patch was fine and I added a 'Reviewed-by:'
tag.

Sure, sorry about my confusing comment.

What I meant is that it has no direct effect on correctness of TCP
stack. I could not cook a packetdrill test that shows the difference
before and after your patch.

BTW, in the following sequence :

A)   Fetch high-res timestamp and store in X
B)   Use X

B) Can use a quite old value of X, depending on scheduling (preempt
kernels or interrupt handling)

TCP really does not care of how accurate X is, it is a best effort.

I agreed. In e.g., hard interrupt storm, this extra refreshing is just
make the expected delay smaller under the same condition.

For RTX packets, it is even more the case, since TCP does not take RTT
samples from packets that were retransmitted.

Indeed, meaning that tcp_clean_rtx_queue implementation never takes.
But for me it seems that there is some possibility RACK algorithm will take it.