netdev - Re: [RFC PATCH 3/3] tcp: Add tunable parameters for TSQ

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 for Android: free password hash cracker in your pocket

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

Message-ID: <20180106192212.vb2okckpvvh5tx7k@judith.localdomain>
Date:   Sat, 6 Jan 2018 20:22:12 +0100
From:   Natale Patriciello <natale.patriciello@...il.com>
To:     Eric Dumazet <eric.dumazet@...il.com>
Cc:     netdev@...r.kernel.org, carloaugusto.grazia@...more.it
Subject: Re: [RFC PATCH 3/3] tcp: Add tunable parameters for TSQ

Thank you, Eric and David, for the time spent in reviewing our work.
Some comments inline:

On 05/01/18 at 03:53am, Eric Dumazet wrote:

> I do not want to add yet another condition in fast path.
> Just put an arbitrary large value in the existing sysctl, no need for
> extra code.

Due to the minimum statement at the line 2202, the algorithm will ignore
the arbitrarily large value and will use ~1 ms of data at the current
rate or 2 segments instead. Therefore, right now there is not the
possibility to completely disable TSQ, while there was in the first
version of it.

> You provide dubious reasons, and no real tests done on various
> hardwares.

We did perform some test internally on a 4.13 kernel for an academic
submission. By varying the parameters, we were able to double the
throughput reachable by any congestion {avoidance, control} algorithm on
top of 2.4GHz networks with a channel of 40 MHz, and to reduce latency
(maybe there is some kind of data waiting that is done at
driver/firmware/hardware level). Then we saw the patch, and we became
aware of the community interest in the topic and decided to ask for
feedback on a revised version.

We will for sure increase the number of test cases (including CPU usage)
and report as soon as the academic world allows us. We are happily using
Flent for the testing phase.

> A linux host can have one 10Gbit NIC and a wifi adapter, they require
> different tunings.

This is an excellent example that we did not consider while developing
the patch. Thanks.

> This is why we added sk_pacing_shift_update(). If this needs
> refinement, lets talk.

We believe that it is fundamental to give the user the runtime control
of the algorithm, which right now starts with latency-saving default
values but is tailored for a specific kind of network. As you pointed
out, these should be tuned per-interface. In the following days, we will
perform more focused testing, trying to assess if there are cases in
which a fine-tuning is preferable to a logarithmic one.

Meanwhile, what would be the best way to expose sk_pacing_shift to the
userspace?

Thank you again