netdev - Re: BQL + Basic Latency under load results - 100Mbit, GSO/TSO off, pfifo

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] [day] [month] [year] [list]

Date:	Tue, 03 Jan 2012 12:52:37 -0500 (EST)
From:	David Miller <davem@...emloft.net>
To:	eric.dumazet@...il.com
Cc:	dave.taht@...il.com, jg@...edesktop.org, shemminger@...tta.com,
	jch@....jussieu.fr, nichols@...lere.com, netdev@...r.kernel.org
Subject: Re: BQL + Basic Latency under load results - 100Mbit, GSO/TSO off,
 pfifo_fast vs SFQ vs QFQ

From: Eric Dumazet <eric.dumazet@...il.com>
Date: Mon, 02 Jan 2012 05:33:31 +0100

> [PATCH net-next] sch_sfq: dont put new flow at the end of flows
> 
> SFQ enqueue algo puts a new flow _behind_ all pre-existing flows in the
> circular list. In fact this is probably an old SFQ implementation bug.
> 
> 100 Mbits = ~8333 full frames per second, or ~8 frames per ms.
> 
> With 50 flows, it means your "new flow" will have to wait 50 packets
> being sent before its own packet. Thats the ~6ms.
> 
> We certainly can change SFQ to give a priority advantage to new flows,
> so that next dequeued packet is taken from a new flow, not an old one.
> 
> Reported-by: Dave Taht <dave.taht@...il.com>
> Signed-off-by: Eric Dumazet <eric.dumazet@...il.com>

Applied, thanks Eric.
--
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