From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id E8AEB3CB35 for ; Wed, 21 Aug 2019 17:40:44 -0400 (EDT) Received: from mail-ed1-f70.google.com (mail-ed1-f70.google.com [209.85.208.70]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 3703781F2F for ; Wed, 21 Aug 2019 21:40:44 +0000 (UTC) Received: by mail-ed1-f70.google.com with SMTP id f3so2136386edx.10 for ; Wed, 21 Aug 2019 14:40:44 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:in-reply-to:references:date :message-id:mime-version:content-transfer-encoding; bh=IoMEX0eHjixXXzBCGFUhAJtw3vuJZ7k5y+k95Knjiug=; b=WpevvljeVYvrAod5pLGMhDKqaJQYS8rsVbn8e9JKhlA7EmMSrG7Zh0DoD8bSLWUcZk sCa4RnEq7CzJjw20nbwkn/JZScOAJ6oH4/2zmz+DTEK45oupsF+D0y5UT/RSlbHE/iFL VGXCF0tyHqeN6ygYYULm1KW8G1dB2g7a4GrZ2U2SPfrMzS+I3yoOM0ZJob2e3F1V3KNt a4Ku75UJeSYn7cPKmZpAAB0F9HZ2KWQcF/UBRv9AhXGCvUqQQ1hixL+SBBsCsx5jIzLd eBlB+RxZ6OnMzKboPL/O/Mud2GhxEsezGiWCkDkSC/82fVe6EEsg6DO3dR1porJVNldo tv2w== X-Gm-Message-State: APjAAAXxBT1BmYFpzOMwuEVV2buPmY+Y82unyEcsf2zwf8bUq+TYb5Fi qFcs4tUuH1wEhYqEvMe8HU0zDx9Uhonbt6hypwq1J+nntwnO19kpD6mViKG2KGCoTqm8VlMDeDC +YBTNOTbXoAd+LSCQ+9iCYg== X-Received: by 2002:a17:906:314c:: with SMTP id e12mr21630061eje.285.1566423642736; Wed, 21 Aug 2019 14:40:42 -0700 (PDT) X-Google-Smtp-Source: APXvYqxe+Vi+Xqg4m2ugRVLFXiBwhWdccK1Yu2zRyHKxNYTKpujOkwA+Khp8K9NkspQriGyw8D1WCQ== X-Received: by 2002:a17:906:314c:: with SMTP id e12mr21630049eje.285.1566423642525; Wed, 21 Aug 2019 14:40:42 -0700 (PDT) Received: from alrua-x1.borgediget.toke.dk ([2a00:7660:6da:443::2]) by smtp.gmail.com with ESMTPSA id o11sm3329204ejd.68.2019.08.21.14.40.41 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 21 Aug 2019 14:40:41 -0700 (PDT) Received: by alrua-x1.borgediget.toke.dk (Postfix, from userid 1000) id 83B31181CEF; Wed, 21 Aug 2019 23:40:41 +0200 (CEST) From: Toke =?utf-8?Q?H=C3=B8iland-J=C3=B8rgensen?= To: Dave Taht , Sebastian Gottschall Cc: cake@lists.bufferbloat.net In-Reply-To: <87v9uqea3x.fsf@taht.net> References: <384866b4-4c91-cf2c-c267-ee4036e5fbf7@newmedia-net.de> <87wof7sriw.fsf@toke.dk> <6782ec15-30eb-63b0-f54f-376c5e6b840b@newmedia-net.de> <87tvabsp99.fsf@toke.dk> <74bccc2b-b805-255f-b6a7-83ade9af6765@newmedia-net.de> <87r25fsn70.fsf@toke.dk> <54438C64-C613-438E-9CB9-6C6D0C5EAFA0@gmail.com> <87sgpvflo4.fsf@taht.net> <87wof6rf7t.fsf@toke.dk> <7656FCDE-C590-4B0C-B191-B9FAC928A762@gmail.com> <5eb4c395-c718-2d28-65a7-9762cf8d5bea@newmedia-net.de> <47AD5102-B66F-44A5-AADE-D167ECB94A61@gmx.de> <1d772664-b6cc-a528-9725-96a431032875@newmedia-net.de> <87v9uqea3x.fsf@taht.net> X-Clacks-Overhead: GNU Terry Pratchett Date: Wed, 21 Aug 2019 23:40:41 +0200 Message-ID: <87tvaap57q.fsf@toke.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Cake] pie in dd-wrt X-BeenThere: cake@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: Cake - FQ_codel the next generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Aug 2019 21:40:45 -0000 Dave Taht writes: > Sebastian Gottschall writes: > >> Am 21.08.2019 um 18:21 schrieb Sebastian Moeller: >>> >>> On August 21, 2019 6:12:03 PM GMT+02:00, Sebastian Gottschall wrote: >>>> thats rather old. i rewrote all the qos code in the last 4 or 5 days. >>>> so >>>> things might be changed. next phase is bringing all the link level >>>> detail configuration stuff into the gui which will be done >>>> tomorrow or at least still within this week. >>>> i also added now cake to some smaller low budged routers with limited >>>> resources, so see how it runs. i had bad experiences with fq_codel in >>>> the past due some high memory usage. >>>> especially since its hard coded somewhat into the wireless ath9k >>>> driver. >>>> so i already modded it for more efficient handling. 4 mb max per queue >>>> is simply too much for=C2=A0 a 32 mb ram based router. >>> This is why I'm sqm we reduced the queued packet maximum m to around 10= 00, and also why cake has an explicit memlimit keyword. >> yeah but does this help if fq_codel is hardcoded into mac80211? >> fq_codel has a memlimit=C2=A0 keyword too btw. its fixed to 4MB. i reduc= ed >> it to 256kb on low memory architectures. no other way to get around >> OOM problems >> mac80211=C2=A0 does always make use of fq_codel. it has a own build in >> implementation > > Certainly memory limits are a huge problem throughout complex qdiscs, > especially when stacked up (eg hfsc 1 -> qdiscx hfsc 2 -> qdisc x), > and=20 > > OOMs suck. Particularly as few test packet flooding their devices > after setting up a complex qdisc system.=20 > > Bytes =3D time. It doesn't matter how many queues you have. This > to me has always been one of the biggest flaws of the tc subsystem > in general is that the total amount of memory in use on > a given physical interface should be managed by the topmost layer. > > Same problem for wifi in multiple SSIDs... it's still just one device. > > However we do need enough bytes to keep the device busy and there > are other problems with per packet limits leading me to prefer > using just memory limits. One is, that your typical ack packet > coming off the rx ring is actually 2k in size, not 64 bytes. > I had at one point (in openwrt) something that took small packets > and copied them to a smaller allocation which took pressure off the > memory allocator. > > I've kind of lost track, did the ath9k wifi stuff use 1 allocation for > all 4 hw queues? I'm afraid to look this morning... (and I'm not big > on the 4 hw queues either) The memory limit in mac80211 is global per phy. -Toke