From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lf0-x243.google.com (mail-lf0-x243.google.com [IPv6:2a00:1450:4010:c07::243]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 02AB43B2F4; Wed, 6 Apr 2016 02:03:57 -0400 (EDT) Received: by mail-lf0-x243.google.com with SMTP id t203so177325lfd.0; Tue, 05 Apr 2016 23:03:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=CQ2x5RqLhM25liTgrAKzX/bocVODr80w4BaocUePcTA=; b=0nW1fEy9Bp2sugZeZjigiQm6urkQFKwzZr63tLuVrHgHZv1NvUfpFvunFUxnxu6hH8 IFewomd3ctP03ecjEg8Yn2O/BKXXZ1EEfCFHrOHwTPg/0ERpY1K2MX5QMs4gaP+Smoct h4MS47LyZHO3KbzjeQW0W8RLOJK3lawN7u/AAtUgT2gz6cLq1rKAU3Zf3euyAcg13+wZ qTk+3Ed6siRgoA8Pyd7g9DNnwZEdQEbKUrGtX8FQ7YFMOWkrWrolaqgioEskzogVjfo/ B5MZteK+ArShniZeC6D4Yu0zZJmxPgg0zUUhOFtYuaqN1Fn8ZLMBoRQZKfVyi7gxaN+6 bCAQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=CQ2x5RqLhM25liTgrAKzX/bocVODr80w4BaocUePcTA=; b=UTwi10cpITvSpahlG/iiTmTfs6/P/+91J5gCwN9899jVydICXN6n4jjmgU3F6OawEO tOTqLlvucQV1fj2ivPTg2a2D4aVrcrlh7mT21luUFXpIUKzZ4g0aoIBLriGRffmh7ikY SZYfGBqlmOtmXBJCX7TJrS68Tq26Iv2PmE8yyV/zf1mLVQwoeyLKqMDqQZesC5ZmJ+Vt T98TvMggWGvjQILK0TeEuw300vgLv6Q2yHzVX1rdvBt5f8LAp6Ea5gSGQsMS4RXJ0ziA WAXOQeLxMPi5suuA5H7Q2woJFo8if4/3n9KbeQeYTEofFKiWiOxjskZ0zuccnY5E7cfE g8sA== X-Gm-Message-State: AD7BkJIH51dDvi7u7ufK9mAjBL7yGuNBxbPC8vYdxwI6ShzB0S9zVnumAo7nviiE+kFRqw== X-Received: by 10.25.19.99 with SMTP id j96mr13121319lfi.114.1459922636699; Tue, 05 Apr 2016 23:03:56 -0700 (PDT) Received: from bass.home.chromatix.fi (37-33-67-252.bb.dnainternet.fi. [37.33.67.252]) by smtp.gmail.com with ESMTPSA id o187sm213565lfo.26.2016.04.05.23.03.55 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 05 Apr 2016 23:03:56 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Jonathan Morton In-Reply-To: Date: Wed, 6 Apr 2016 09:03:50 +0300 Cc: Johannes Berg , make-wifi-fast@lists.bufferbloat.net, linux-wireless , codel@lists.bufferbloat.net Content-Transfer-Encoding: quoted-printable Message-Id: <2233FCEB-7412-4F22-B262-068AFBB2FDCB@gmail.com> References: <1458898052-20601-1-git-send-email-michal.kazior@tieto.com> <1459420104-31554-1-git-send-email-michal.kazior@tieto.com> <1459420104-31554-2-git-send-email-michal.kazior@tieto.com> <1459864656.18188.60.camel@sipsolutions.net> To: Michal Kazior X-Mailer: Apple Mail (2.3112) Subject: Re: [Make-wifi-fast] [PATCHv2 1/2] mac80211: implement fair queuing per txq X-BeenThere: make-wifi-fast@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2016 06:03:58 -0000 > On 6 Apr, 2016, at 08:35, Michal Kazior = wrote: >=20 > Packets can be destined to different stations/txqs. At enqueue time I > do a partial hash of a packet to get an "index" which I then use to > address a txq_flow from per-radio list (out of 4096 of them). You can > end up with a situtation like this: > - packet A hashing to X destined to txq P which is VI > - packet B hashing to X destined to txq Q which is BK >=20 > You can't use the same txq_flow for both A and B because you want to > maintain packets per txqs more than you want to maintain them per flow > (you don't want to queue BK traffic onto VI or vice versa as an > artifact, do you? ;). When a txq_flow doesn't have a txqi it is bound. > Later, if a collision happens (i.e. resulting txq_flow has non-NULL > txqi) the "embedded" per-txq flow is used: >=20 > struct txq_info { > - struct sk_buff_head queue; > + struct txq_flow flow; // <--- this >=20 > When txq_flow becomes empty its txqi is reset. >=20 > The embedded flow is otherwise treated like any other flow, i.e. it > can be linked to old_flows and new_flows. This smells like a very fragile and complex solution to the collision = problem. You may want to look at how Cake solves it. I use a separate pool of flows per traffic class (essentially, = VO/VI/BE/BK), and there is also a set-associative hash to take care of = the birthday problem. The latter has an order-of-magnitude effect on = the general flow collision rate once you get into the tens of flows, for = very little CPU cost. - Jonathan Morton