On Sun, 2017-10-22 at 20:40 -0700, Eric Dumazet wrote:
> On Mon, 2017-10-23 at 12:26 +0900, Koichiro Den wrote:
>
> > 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.
