netdev - Re: [Patch net-next 3/3] tcp: decouple TLP timer from RTO timer

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAM_iQpUyMjdDO9gbrzqS3f3A2LW9dFJRuZfcm=EsJwDAdZdMxA@mail.gmail.com>
Date:   Wed, 23 Oct 2019 11:30:01 -0700
From:   Cong Wang <xiyou.wangcong@...il.com>
To:     Eric Dumazet <edumazet@...gle.com>
Cc:     netdev <netdev@...r.kernel.org>, Yuchung Cheng <ycheng@...gle.com>,
        Neal Cardwell <ncardwell@...gle.com>
Subject: Re: [Patch net-next 3/3] tcp: decouple TLP timer from RTO timer

On Wed, Oct 23, 2019 at 11:14 AM Eric Dumazet <edumazet@...gle.com> wrote:
> > In case you misunderstand, the CPU profiling I used is captured
> > during 256 parallel TCP_STREAM.
>
> When I asked you the workload, you gave me TCP_RR output, not TCP_STREAM :/
>
> "A single netperf TCP_RR could _also_ confirm the improvement:"

I guess you didn't understand what "also" mean? The improvement
can be measured with both TCP_STREAM and TCP_RR, only the
CPU profiling is done with TCP_STREAM.

BTW, I just tested an unpatched kernel on a machine with 64 CPU's,
turning on/off TLP makes no difference there, so this is likely related
to the number of CPU's or hardware configurations. This explains
why you can't reproduce it on your side, so far I can only reproduce
it on one particular hardware platform too, but it is real.

If you need any other information, please let me know.

Thanks.