From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail2.tohojo.dk (mail2.tohojo.dk [77.235.48.147]) (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 1E0D43B2AE for ; Fri, 30 Sep 2016 10:35:54 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail2.tohojo.dk DKIM-Filter: OpenDKIM Filter v2.10.3 mail2.tohojo.dk 7BFA341622 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=toke.dk; s=201310; t=1475246149; bh=H32Lyz0GeOHO94JBUmZ+hKnBX8szJ2Ko1BOSlKCp5d4=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=NmXkn6B9IHfbsxAl5FnEq/VxI057G2byVHwKJjQJ9OfV3hHpqShAwT/bff0LCwYtA DTtpfnFC7fVqvyUk4o//Ab9Z/DCYlE+lOM0zdfptCT2Os+klJ1P5TC2t4t088BryTQ WeGu81+k86ih06pQi5kEO2CFr9eHJol1S7svZhr8= Received: by alrua-kau.kau.toke.dk (Postfix, from userid 1000) id 5488BC4024B; Fri, 30 Sep 2016 16:35:49 +0200 (CEST) From: =?utf-8?Q?Toke_H=C3=B8iland-J=C3=B8rgensen?= To: Johannes Berg Cc: make-wifi-fast@lists.bufferbloat.net, linux-wireless@vger.kernel.org, netdev@vger.kernel.org References: <20160923195911.4572-1-toke@toke.dk> <20160923195911.4572-4-toke@toke.dk> <1475235230.17481.43.camel@sipsolutions.net> <87twcx5zll.fsf@toke.dk> <1475239915.17481.63.camel@sipsolutions.net> Date: Fri, 30 Sep 2016 16:35:49 +0200 In-Reply-To: <1475239915.17481.63.camel@sipsolutions.net> (Johannes Berg's message of "Fri, 30 Sep 2016 14:51:55 +0200") X-Clacks-Overhead: GNU Terry Pratchett Message-ID: <87h98x5ube.fsf@toke.dk> MIME-Version: 1.0 Content-Type: text/plain 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 14:35:54 -0000 Johannes Berg writes: >> > 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. Hmm, I'll talk it over with some of the LEDE people who are more used to dealing with these sorts of memory-constrained devices than I am. Will send a patch if we come up with a good solution :) -Toke