netdev - Re: [PATCH v3 01/10] dql: Dynamic queue limits

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: <CAA93jw5Mopc8E7MPFrKDNz0eBAwskW-2iGz0n=qBbmTfhT7ejg@mail.gmail.com>
Date:	Wed, 23 Nov 2011 18:27:47 +0100
From:	Dave Taht <dave.taht@...il.com>
To:	Tom Herbert <therbert@...gle.com>
Cc:	davem@...emloft.net, netdev@...r.kernel.org
Subject: Re: [PATCH v3 01/10] dql: Dynamic queue limits

On Wed, Nov 23, 2011 at 6:52 AM, Tom Herbert <therbert@...gle.com> wrote:
> Implementation of dynamic queue limits (dql).  This is a libary which
> allows a queue limit to be dynamically managed.  The goal of dql is
> to set the queue limit, number of objects to the queue, to be minimized
> without allowing the queue to be starved.

Dear Tom:

I have been fiddling with v3 of your patch series for much of the day,
artificially imposing 10Mbit and 100Mbit limits on the network with
ethtool.

The performance of multiple tcp streams 'feels' quite good across
multiple, saturating workloads over the LFN, and short distances, but
the data I collected today was too muddled and confusing to publish.

I need to finish patching this into a couple other boxes before
rebuilding the testbed,
and judging from the code review comments it would seem a good idea to
wait for another go-round.

I did a build on top of commit b4bbb02934e4511d9083f15c23e90703482e84ad

for ubuntu here:

http://huchra.bufferbloat.net/~d/bql/

the usual caveats apply to development kernels... I ran all day without a crash,
testing the e1000e driver, the qfq qdisc, red, and sfq.

two drivers (forcedeth, bnx2x_) did not apply on top of that commit.

If anyone cares, here are also the various QFQ + RED scheduler scripts
I've been fiddling with. These seemed to help at 100Mbit, in the
previous series.

https://github.com/dtaht/deBloat/blob/master/wip/

eqfq (pure qfq), eqfq.red and eqfq.red.10mbit are the only three
seriously tested at the moment.

Would love to know what/how qfq does to cpu at a gigabit (some red
tuning would be needed on top of the script) on a machine that can
drive it, now that there's drivers that stop gobbling packets so
greedily...
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html