netdev - Re: [net-next PATCH 1/1 V4] qdisc: bulk dequeue support for qdiscs with TCQ_F

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: <20140929221431.3e322aab@redhat.com>
Date:	Mon, 29 Sep 2014 22:14:31 +0200
From:	Jesper Dangaard Brouer <brouer@...hat.com>
To:	Jesper Dangaard Brouer <brouer@...hat.com>
Cc:	Tom Herbert <therbert@...gle.com>,
	Jamal Hadi Salim <jhs@...atatu.com>,
	Eric Dumazet <eric.dumazet@...il.com>,
	Linux Netdev List <netdev@...r.kernel.org>,
	"David S. Miller" <davem@...emloft.net>,
	Alexander Duyck <alexander.h.duyck@...el.com>,
	Toke Høiland-Jørgensen 
	<toke@...e.dk>, Florian Westphal <fw@...len.de>,
	Dave Taht <dave.taht@...il.com>,
	John Fastabend <john.r.fastabend@...el.com>,
	Daniel Borkmann <dborkman@...hat.com>,
	Hannes Frederic Sowa <hannes@...essinduktion.org>
Subject: Re: [net-next PATCH 1/1 V4] qdisc: bulk dequeue support for qdiscs
 with TCQ_F_ONETXQUEUE


On Thu, 25 Sep 2014 17:23:29 +0200 Jesper Dangaard Brouer <brouer@...hat.com> wrote:
 
> I will redo the tests, once I get home to my testlab, as the remote lab
> I'm using now is annoyingly slow rebooting machines, as we not longer
> have a runtime option for enable/disable (I'm currently in Switzerland).   

I'm going to change the bulking "budget" from 8 packet to 7 packets,
based on my netperf-wrapper test.

I've designed some tests for the tool "netperf-wrapper" that tries to
measure the HoL blocking effect.  I've turned down the link speed to
100Mbit/s on driver igb.  And uses a single TXQ setup
(cmdline: ethtool -L eth1 combined 1).

I can now show some kind of HoL blocking effect.  The strange part is
the HoL effect only occurs above 8 packets, 7 packet and below show no
bad effect of this bulking patch.

Results 100Mbit/s test qdisc_prio_hol, latency in high prio band:
 * GSO: stable average on 2.23ms
 * TSO: varies between min 4.13ms to 4.41ms (range 0.28ms)
 * No bulking: stable average on 1.71ms (3x outliners on 1.95ms)
 * Bulking(8): varies between 1.71ms to 1.95ms (range 0.24ms)
 * Bulking(7): stable average on 1.71ms (1x outliner  on 1.95ms)
 * Bulking(6): stable average on 1.71ms (3x outliners on 1.91ms)
 * Bulking(5): stable average on 1.71ms (1x outliner  on 1.91ms)
 * Bulking(5): stable average on 1.71ms (1x outliner  on 1.91ms)
 * Bulking(4): stable average on 1.71ms (0x outliner)

Bulking(8) the calculation:
 * Added delay were 0.24ms (1.95 - 1.71ms) corrosponding to 3000 bytes
 * 1500 bytes *8 / 100Mbit = 0.12 ms
 * (100*10^6)*(1.95/10^3)/8 = 24375 bytes
 * (100*10^6)*(1.71/10^3)/8 = 21375 bytes
 * Added HoL: 3000 bytes
 * Still compared to TSO and GSO, the added HoL blocking is small.


-- 
Best regards,
  Jesper Dangaard Brouer
  MSc.CS, Sr. Network Kernel Developer at Red Hat
  Author of http://www.iptv-analyzer.org
  LinkedIn: http://www.linkedin.com/in/brouer
--
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