From patchwork Mon Jan 2 04:33:31 2012 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Eric Dumazet X-Patchwork-Id: 133793 X-Patchwork-Delegate: davem@davemloft.net Return-Path: X-Original-To: patchwork-incoming@ozlabs.org Delivered-To: patchwork-incoming@ozlabs.org Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by ozlabs.org (Postfix) with ESMTP id 038D7B6FA2 for ; Mon, 2 Jan 2012 15:34:02 +1100 (EST) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751861Ab2ABEdi (ORCPT ); Sun, 1 Jan 2012 23:33:38 -0500 Received: from mail-ww0-f44.google.com ([74.125.82.44]:64450 "EHLO mail-ww0-f44.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751800Ab2ABEdh (ORCPT ); Sun, 1 Jan 2012 23:33:37 -0500 Received: by wgbdr13 with SMTP id dr13so26233696wgb.1 for ; Sun, 01 Jan 2012 20:33:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:subject:from:to:cc:date:in-reply-to:references :content-type:x-mailer:content-transfer-encoding:mime-version; bh=+6dMpMzlsIzyUrj20fy2ZbO6Icim54W0ZjwYRhHSY0o=; b=dbbhasJyyjQj+2ydS3fgN8ty4kb3PcpbS+VO+mHTwmC6DW/C47JrUGRHKMSPir1cDc d6tPzIkzGjOBfSdSuVn/KQDmRerHaZgNcnWXbocIxKtOf1ho0hXi2+PfwGJikJMQ6MA4 ZDF7TSwRtY3ploj39dlxh7076LEKMLH+li6WI= Received: by 10.227.202.211 with SMTP id ff19mr46991561wbb.15.1325478815325; Sun, 01 Jan 2012 20:33:35 -0800 (PST) Received: from [192.168.1.97] (66.144.72.86.rev.sfr.net. [86.72.144.66]) by mx.google.com with ESMTPS id 28sm49114224wby.3.2012.01.01.20.33.32 (version=SSLv3 cipher=OTHER); Sun, 01 Jan 2012 20:33:33 -0800 (PST) Message-ID: <1325478811.2526.10.camel@edumazet-laptop> Subject: Re: BQL + Basic Latency under load results - 100Mbit, GSO/TSO off, pfifo_fast vs SFQ vs QFQ From: Eric Dumazet To: Dave Taht Cc: jg@freedesktop.org, Stephen Hemminger , Juliusz Chroboczek , Kathleen Nichols , netdev Date: Mon, 02 Jan 2012 05:33:31 +0100 In-Reply-To: References: X-Mailer: Evolution 3.2.1- Mime-Version: 1.0 Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org Le lundi 02 janvier 2012 à 00:17 +0100, Dave Taht a écrit : > QFQ wins even bigger vs SFQ at 50 iperfs > > http://www.teklibre.com/~d/bloat/pfifo_sfq_vs_qfq_linear50.png > > And I think it's going to win even bigger at 10 Mbit. > Happy new year ! This makes no sense to me for such a low amount of flows, SFQ should perform the same than QFQ :) You dont find out why it is so. Please try following patch : [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 Signed-off-by: Eric Dumazet --- -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html diff --git a/net/sched/sch_sfq.c b/net/sched/sch_sfq.c index c23b957..f7f62a5 100644 --- a/net/sched/sch_sfq.c +++ b/net/sched/sch_sfq.c @@ -366,11 +366,11 @@ sfq_enqueue(struct sk_buff *skb, struct Qdisc *sch) if (slot->qlen == 1) { /* The flow is new */ if (q->tail == NULL) { /* It is the first flow */ slot->next = x; + q->tail = slot; } else { slot->next = q->tail->next; q->tail->next = x; } - q->tail = slot; slot->allot = q->scaled_quantum; } if (++sch->q.qlen <= q->limit)