On Sun, 2017-10-22 at 21:31 -0700, Eric Dumazet wrote:
> On Mon, 2017-10-23 at 13:28 +0900, Koichiro Den wrote:
>
> > 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.
>
> As long as tp->tcp
On Mon, 2017-10-23 at 13:28 +0900, Koichiro Den wrote:
> 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.
As long as tp->tcp_mstamp is monotonically increasing (and it is ;) ),
RACK will behav
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:'
>
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.
What I meant is that it has no direct effect on correctness of TCP
On Sun, 2017-10-22 at 10:11 -0700, Eric Dumazet wrote:
> On Sun, 2017-10-22 at 09:49 -0700, Eric Dumazet wrote:
>
> > Here is the test I cooked.
> >
> > Note that it actually passes just fine, do I am wondering if your patch
> > is needed after all..
> >
>
> Oh this is because tcp_mstamp_refres
On Sun, 2017-10-22 at 09:49 -0700, Eric Dumazet wrote:
> Here is the test I cooked.
>
> Note that it actually passes just fine, do I am wondering if your patch
> is needed after all..
>
Oh this is because tcp_mstamp_refresh() is called from tcp_write_xmit()
and tcp_write_xmit() is directly call
On Sun, 2017-10-22 at 21:59 +0900, Koichiro Den wrote:
> On Sat, 2017-10-21 at 22:21 -0700, Eric Dumazet wrote:
> > On Sun, 2017-10-22 at 13:10 +0900, Koichiro Den wrote:
> > > On Sat, 2017-10-21 at 20:52 -0700, Eric Dumazet wrote:
> > > > On Sun, 2017-10-22 at 12:38 +0900, Koichiro Den wrote:
> >
On Sat, 2017-10-21 at 22:21 -0700, Eric Dumazet wrote:
> On Sun, 2017-10-22 at 13:10 +0900, Koichiro Den wrote:
> > On Sat, 2017-10-21 at 20:52 -0700, Eric Dumazet wrote:
> > > On Sun, 2017-10-22 at 12:38 +0900, Koichiro Den wrote:
> > > > When retransmission on TSQ handler was introduced in the co
On Sun, 2017-10-22 at 13:10 +0900, Koichiro Den wrote:
> On Sat, 2017-10-21 at 20:52 -0700, Eric Dumazet wrote:
> > On Sun, 2017-10-22 at 12:38 +0900, Koichiro Den wrote:
> > > When retransmission on TSQ handler was introduced in the commit
> > > f9616c35a0d7 ("tcp: implement TSQ for retransmits"),
On Sat, 2017-10-21 at 20:52 -0700, Eric Dumazet wrote:
> On Sun, 2017-10-22 at 12:38 +0900, Koichiro Den wrote:
> > When retransmission on TSQ handler was introduced in the commit
> > f9616c35a0d7 ("tcp: implement TSQ for retransmits"), the retransmitted
> > skbs' timestamps were updated on the act
On Sun, 2017-10-22 at 12:38 +0900, Koichiro Den wrote:
> When retransmission on TSQ handler was introduced in the commit
> f9616c35a0d7 ("tcp: implement TSQ for retransmits"), the retransmitted
> skbs' timestamps were updated on the actual transmission. In the later
> commit 385e20706fac ("tcp: use
On Sat, 2017-10-21 at 20:52 -0700, Eric Dumazet wrote:
> Very nice catch, thanks a lot Koichiro.
>
> This IMO would target net tree, since it is a bug fix.
>
> Fixes: 385e20706fac ("tcp: use tp->tcp_mstamp in output path")
Reviewed-by: Eric Dumazet
When retransmission on TSQ handler was introduced in the commit
f9616c35a0d7 ("tcp: implement TSQ for retransmits"), the retransmitted
skbs' timestamps were updated on the actual transmission. In the later
commit 385e20706fac ("tcp: use tp->tcp_mstamp in output path"), it stops
being done so. In th
13 matches
Mail list logo
