On Wed, Jan 18, 2017 at 1:16 PM, Eric Dumazet wrote:
>
> On Wed, Jan 18, 2017 at 10:13 AM, Yuchung Cheng wrote:
> > On Wed, Jan 18, 2017 at 9:35 AM, Eric Dumazet wrote:
> >>
> >> On Wed, Jan 18, 2017 at 9:32 AM, Alexey Kodanev
> >> wrote:
> >> > Hi Eric,
> >> >
> >> > On 01/13/2017 08:07 PM, Al
On Wed, Jan 18, 2017 at 1:27 PM, Yuchung Cheng wrote:
> Hi Eric: yeah I think the test was just due to the TSO chunking
> difference between prod and upstream, which I was able to avoid with
> this patch re-suited by Neal in b/34128974. In fact, this patch
> enables me to run all recovery tests on
Googler-only
Hi Eric: yeah I think the test was just due to the TSO chunking
difference between prod and upstream, which I was able to avoid with
this patch re-suited by Neal in b/34128974. In fact, this patch
enables me to run all recovery tests on upstream kernels for my RACK
patch set.
Neal: c
On Wed, Jan 18, 2017 at 10:13 AM, Yuchung Cheng wrote:
> On Wed, Jan 18, 2017 at 9:35 AM, Eric Dumazet wrote:
>>
>> On Wed, Jan 18, 2017 at 9:32 AM, Alexey Kodanev
>> wrote:
>> > Hi Eric,
>> >
>> > On 01/13/2017 08:07 PM, Alexey Kodanev wrote:
>> >
>>
>> > Looks like max_window not correctly ini
On Wed, Jan 18, 2017 at 9:35 AM, Eric Dumazet wrote:
>
> On Wed, Jan 18, 2017 at 9:32 AM, Alexey Kodanev
> wrote:
> > Hi Eric,
> >
> > On 01/13/2017 08:07 PM, Alexey Kodanev wrote:
> >
>
> > Looks like max_window not correctly initialized for tfo sockets.
> > On my test machine it has set to '559
On Wed, Jan 18, 2017 at 9:32 AM, Alexey Kodanev
wrote:
> Hi Eric,
>
> On 01/13/2017 08:07 PM, Alexey Kodanev wrote:
>
> Looks like max_window not correctly initialized for tfo sockets.
> On my test machine it has set to '5592320' in tcp_fastopen_create_child().
>
> This diff fixes the issue, the
Hi Eric,
On 01/13/2017 08:07 PM, Alexey Kodanev wrote:
Hi Eric,
On 13.01.2017 18:35, Eric Dumazet wrote:
I would suggest to clamp MSS to half the initial window, but I guess
this is impractical since window in SYN/SYNACK are not scaled.
Looks like max_window not correctly initialized for tf
On Fri, 2017-01-13 at 12:32 -0500, Neal Cardwell wrote:
> On Fri, Jan 13, 2017 at 12:14 PM, Eric Dumazet wrote:
> >
> > On Fri, Jan 13, 2017 at 9:07 AM, Alexey Kodanev
> > wrote:
> > > Hi Eric,
> > > On 13.01.2017 18:35, Eric Dumazet wrote:
> >
> > >> Care to send a packetdrill test so that we ha
On Fri, Jan 13, 2017 at 12:14 PM, Eric Dumazet wrote:
>
> On Fri, Jan 13, 2017 at 9:07 AM, Alexey Kodanev
> wrote:
> > Hi Eric,
> > On 13.01.2017 18:35, Eric Dumazet wrote:
>
> >> Care to send a packetdrill test so that we have a clear picture of what
> >> is going on ?
> >
> > Is it capable of m
On Fri, Jan 13, 2017 at 9:07 AM, Alexey Kodanev
wrote:
> Hi Eric,
> On 13.01.2017 18:35, Eric Dumazet wrote:
>> Care to send a packetdrill test so that we have a clear picture of what
>> is going on ?
>
> Is it capable of making two connections in the single test, one after
> another?
Absolutely
Hi Eric,
On 13.01.2017 18:35, Eric Dumazet wrote:
> On Fri, 2017-01-13 at 18:01 +0300, Alexey Kodanev wrote:
>> Hi,
>>
>> Got the issue when running LTP/netstress test on localhost with mss
>> greater than the send window advertised by client (right after 3WHS).
>> Here is the testscenario that can
On Fri, 2017-01-13 at 18:01 +0300, Alexey Kodanev wrote:
> Hi,
>
> Got the issue when running LTP/netstress test on localhost with mss
> greater than the send window advertised by client (right after 3WHS).
> Here is the testscenario that can reproduce this:
Hi Alexey
So this is a combination of
Hi,
Got the issue when running LTP/netstress test on localhost with mss
greater than the send window advertised by client (right after 3WHS).
Here is the testscenario that can reproduce this:
TCP client is sending 32 bytes request, TCP server replies with 65KB answer.
net.ipv4.tcp_fastopen set to
13 matches
Mail list logo