From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-x229.google.com (mail-wm0-x229.google.com [IPv6:2a00:1450:400c:c09::229]) (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 DB6DB3B2AF for ; Tue, 22 Mar 2016 02:51:07 -0400 (EDT) Received: by mail-wm0-x229.google.com with SMTP id p65so149391825wmp.0 for ; Mon, 21 Mar 2016 23:51:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tieto.com; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-transfer-encoding; bh=SxJpEuvgW1lb43QWj8A65FJAIevmPBeFRvtctcZdau8=; b=jLcL+s5/8EpIP/0wn3PBRTF2PO8u30xKh+wXOJXGeem3o2C7wJ7BU2B+TKxtxsxv8Y Do198AYL53YXNBqprnrvKDNTzAIwIWRiNYnLfPAa+2B/953stV56r+zCDkuRis/70rsn CkFDSorVrOULJ9lk4KQktxnvV7BKMM4vUOGLo= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-transfer-encoding; bh=SxJpEuvgW1lb43QWj8A65FJAIevmPBeFRvtctcZdau8=; b=bVsMXXtQ8/knrrns6MqNiS/iuvmqjxtryY/0isfSxSlnqTi7MYW68qWIApSSAMBqr6 Nx/1V2VRqUqchnllh4YrFfsqViAzPsZ1xqQdi1k58lKmzEhbe2phupWAokT+4abGRwDL e5UuF/2VNOte0K4PtmPgkoSJIJiao9fuJ+qoaIOIJQGE3JB3IoEpawxcXbvZlQIv7Nk5 vewPC2AxgSAvB2zBnc2MHfSumQpg2XsG2qoGs/VW52u6nEi+PqCSTZEFfNCd/Wh+mVoV KA7uBtbgYhpNK/FZGf01JaBRXEsvR97K29oxSPGJjlbxvqNv8JQBXv5LNT/O8dkfuwR0 VrjA== X-Gm-Message-State: AD7BkJJFvmBOL1OwB3cgb7HOY7Rm0T5T9PlDcHntLGisxfdmPpigXGOZMOE98Zdr4otnCmXVLa2YtBwlc68SrwlckaTNAtBdmRdJOTzep9oh5XQl2xDsYf1EpXWZ+i2DY3vfZsmoOUCayBRysHg7vmQ1ttey5mTLdTLw8g== MIME-Version: 1.0 X-Received: by 10.28.178.209 with SMTP id b200mr18419768wmf.98.1458629466853; Mon, 21 Mar 2016 23:51:06 -0700 (PDT) Received: by 10.194.21.73 with HTTP; Mon, 21 Mar 2016 23:51:06 -0700 (PDT) In-Reply-To: References: <1458123478-1795-1-git-send-email-michal.kazior@tieto.com> <1458123478-1795-2-git-send-email-michal.kazior@tieto.com> Date: Tue, 22 Mar 2016 07:51:06 +0100 Message-ID: From: Michal Kazior To: David Lang Cc: linux-wireless , Emmanuel Grumbach , Network Development , "ath10k@lists.infradead.org" , codel@lists.bufferbloat.net, make-wifi-fast@lists.bufferbloat.net, Johannes Berg , Tim Shepard Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-DomainID: tieto.com Subject: Re: [Make-wifi-fast] [RFCv2 1/3] mac80211: implement fq_codel for software queuing 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: Tue, 22 Mar 2016 06:51:08 -0000 On 22 March 2016 at 02:35, David Lang wrote: > On Wed, 16 Mar 2016, Michal Kazior wrote: > >> Since 11n aggregation become important to get the >> best out of txops. However aggregation inherently >> requires buffering and queuing. Once variable >> medium conditions to different associated stations >> is considered it became apparent that bufferbloat >> can't be simply fought with qdiscs for wireless >> drivers. > > If the network is quiet enough, don't do any buffering, but in almost all > situations you are going to need to buffer starting no later than the sec= ond > packet you try to send. > > Don't try to make queueing occur, just deal with the queues that form > naturally because you can't transmit data any faster (and work to keep th= em > under some semblence of control) [...] This is what already happens. Queues typically start to build up when hardware tx fifos/queues become busy so by the time they become available you might have a bunch of frames you can aggregate. The patch is more about getting rid of qdiscs because it's inherently hard to teach them how 802.11 aggregation works (per-station per-tid) and the ever-changing nature of per-station tx conditions. I'll update the commit log to better reflect what is being done. Micha=C5=82