[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CADVnQymVniXHxEDW8aA8z+M=G_qNfo+jJfUBrfHycM4-voiDJw@mail.gmail.com>
Date: Mon, 31 Jul 2017 11:49:13 -0400
From: Neal Cardwell <ncardwell@...gle.com>
To: maowenan <maowenan@...wei.com>
Cc: Netdev <netdev@...r.kernel.org>,
David Miller <davem@...emloft.net>,
Yuchung Cheng <ycheng@...gle.com>,
Nandita Dukkipati <nanditad@...gle.com>,
"weiyongjun (A)" <weiyongjun1@...wei.com>,
Chenweilong <chenweilong@...wei.com>,
"Wangkefeng (Kevin)" <wangkefeng.wang@...wei.com>
Subject: Re: [PATCH V3 net-next] TLP: Don't reschedule PTO when there's one
outstanding TLP retransmission
On Sun, Jul 30, 2017 at 11:29 PM, maowenan <maowenan@...wei.com> wrote:
> [Mao Wenan]please refer to the attachment, test.pkt is packetdrill script.
> In test.pcap, packet number 17 is the TLP probe, packet number 218 is the
> retransmission packet because client don't send data packet to server.
> From the capture time, there are about 6 seconds the retransmission
> packet can be sent, and this time can be added more as long as client
> send data packet continually.
> I have reproduced this issue in Linux 4.13-rc3, 3.10, 4.1. Please check the timing
> When you use test.pkt to reproduce in your environment.
Thank you for your very nice packetdrill test case illustrating this
problem! And thanks for verifying that the problem shows up in those
kernel versions.
We are able to run the script in our environment and both verify that
the bug is the one we hypothesized, and verify our proposed patch
fixes it (the RTO for the TLP happens 221ms after the TLP, instead of
~5 secs later). We will send out our proposed patches ASAP.
Thanks!
neal
Powered by blists - more mailing lists