From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from sipsolutions.net (s3.sipsolutions.net [5.9.151.49]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 07A923B260 for ; Fri, 30 Sep 2016 08:51:57 -0400 (EDT) Received: by sipsolutions.net with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.87) (envelope-from ) id 1bpxIB-0002Fc-Va; Fri, 30 Sep 2016 14:51:56 +0200 Message-ID: <1475239915.17481.63.camel@sipsolutions.net> From: Johannes Berg To: Toke =?ISO-8859-1?Q?H=F8iland-J=F8rgensen?= Cc: make-wifi-fast@lists.bufferbloat.net, linux-wireless@vger.kernel.org, netdev@vger.kernel.org Date: Fri, 30 Sep 2016 14:51:55 +0200 In-Reply-To: <87twcx5zll.fsf@toke.dk> References: <20160923195911.4572-1-toke@toke.dk> <20160923195911.4572-4-toke@toke.dk> <1475235230.17481.43.camel@sipsolutions.net> <87twcx5zll.fsf@toke.dk> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.20.5-1 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Subject: Re: [Make-wifi-fast] [PATCH 3/3] mac80211: Set lower memory limit for non-VHT devices 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: Fri, 30 Sep 2016 12:51:57 -0000 > > I kinda see the logic here - we really don't need to queue as much > > if we can't possibly transmit it out quickly - but it seems to me > > we should also throw in some kind of limit that's relative to the > > amount of memory you have on the system? > > Yes, ideally. That goes for FQ-CoDel as well, BTW. LEDE currently > carries a patch for that which just changes the hard-coded default to > another hard-coded default. Not sure how to get a good value to use, > though; and deciding on how large a fraction of memory to use for > packets starts smelling an awful lot like setting policy in the > kernel, doesn't it? Yeah, I agree it does seem awkward. Perhaps we should instead pick a low limit and let users change it more easily (i.e. not debugfs)? I don't know a good answer to this either. johannes