From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oi0-x22f.google.com (mail-oi0-x22f.google.com [IPv6:2607:f8b0:4003:c06::22f]) (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 B011A3B25E; Sun, 15 May 2016 18:47:30 -0400 (EDT) Received: by mail-oi0-x22f.google.com with SMTP id k142so244808993oib.1; Sun, 15 May 2016 15:47:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=jG4MzSJTiWbn6fizRZn5EaUDcJZLkFFUPAGCwHY+klM=; b=ByD+kyKDRuxVrQl+qeUjF001fqD0VMmlszoaPPiFn+77txjr2msiAhaFLk0HUOCjpL 5zAWE8FvyaLYLwnavuk96JEZdkUFs8zDcZsAw9jkKvyORrK58I/wlIHXobDycyY54uzH Ukm7IOzx37cMCs5r85ethF7kvSnYNHjW6O5WY9MdeeGy6Qi9taUqODVaMjzDKbawyZPH aGB3g43CA9ONsh75lPWdydZCIz2Tia1RQXgAc6FoF1WaPdyftGvkaIFLv0A9JjhrYCrm f/Fq1iGUQNxrTq7eVCR+4u4SHzx0unTFsbBdBmejXCs2+A5LKUfkzk9xBJWS81EIN6T8 UL6A== 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; bh=jG4MzSJTiWbn6fizRZn5EaUDcJZLkFFUPAGCwHY+klM=; b=GaBHKS9MhOngNeKGSQL9+28qczmF77MyOJEEwpCVHiJJrFj9YnHX0XfZNLjeDC0POp oNk8Y8bKGeygm49XFjNgujeJAnI6T3HTFYK6YBrEVpgh6+dF7XYmcORFzc1sk7R//Ec0 +8hg4PqfN0iINkoP/18EIfmqyNUERb+CC1o1EfUedB4XRJDrI0Y0Q7nIt8y4/mQ2pGsl AICSRyC/6g7JwlvF43LowvspSqA8hOvMmFbU6/44mvZ52oEVJIuss7cKxl16pNbi/L+e jlk6wbpCXsyh1hXtNI5fyEWX05xHyaSsNBO/RiPMRgRYvN1qKDtNDsqQivqUXN00eS+5 qmhw== X-Gm-Message-State: AOPr4FViQyvo3gcoeWqf6d69H2GLc2IFm6pv4y8tI+icRDH8wPV/RA67dO8DEvzBZHYyZ9lNVOQsU8rRRJii6A== MIME-Version: 1.0 X-Received: by 10.202.4.213 with SMTP id 204mr12967912oie.47.1463352450159; Sun, 15 May 2016 15:47:30 -0700 (PDT) Received: by 10.202.252.9 with HTTP; Sun, 15 May 2016 15:47:30 -0700 (PDT) In-Reply-To: <572DBC21.10209@darbyshire-bryant.me.uk> References: <1462125592.5535.194.camel@edumazet-glaptop3.roam.corp.google.com> <865DA393-262D-40B6-A9D3-1B978CD5F6C6@gmail.com> <1462128385.5535.200.camel@edumazet-glaptop3.roam.corp.google.com> <1462136140.5535.219.camel@edumazet-glaptop3.roam.corp.google.com> <1462201620.5535.250.camel@edumazet-glaptop3.roam.corp.google.com> <1462205669.5535.254.camel@edumazet-glaptop3.roam.corp.google.com> <1462464776.13075.18.camel@edumazet-glaptop3.roam.corp.google.com> <1462476207.13075.20.camel@edumazet-glaptop3.roam.corp.google.com> <20160506114243.4eb4f95e@redhat.com> <572DBC21.10209@darbyshire-bryant.me.uk> Date: Mon, 16 May 2016 01:47:30 +0300 Message-ID: From: Roman Yeryomin To: Kevin Darbyshire-Bryant Cc: Jesper Dangaard Brouer , Eric Dumazet , Felix Fietkau , Dave Taht , make-wifi-fast@lists.bufferbloat.net, =?UTF-8?B?UmFmYcWCIE1pxYJlY2tp?= , ath10k , "netdev@vger.kernel.org" , "codel@lists.bufferbloat.net" , Jonathan Morton Content-Type: text/plain; charset=UTF-8 Subject: Re: [Codel] OpenWRT wrong adjustment of fq_codel defaults (Was: fq_codel_drop vs a udp flood) X-BeenThere: codel@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: CoDel AQM discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 May 2016 22:47:30 -0000 On 7 May 2016 at 12:57, Kevin Darbyshire-Bryant wrote: > > > On 06/05/16 10:42, Jesper Dangaard Brouer wrote: >> Hi Felix, >> >> This is an important fix for OpenWRT, please read! >> >> OpenWRT changed the default fq_codel sch->limit from 10240 to 1024, >> without also adjusting q->flows_cnt. Eric explains below that you must >> also adjust the buckets (q->flows_cnt) for this not to break. (Just >> adjust it to 128) >> >> Problematic OpenWRT commit in question: >> http://git.openwrt.org/?p=openwrt.git;a=patch;h=12cd6578084e >> 12cd6578084e ("kernel: revert fq_codel quantum override to prevent it from causing too much cpu load with higher speed (#21326)") > I 'pull requested' this to the lede-staging tree on github. > https://github.com/lede-project/staging/pull/11 > > One way or another Felix & co should see the change :-) If you would follow the white rabbit, you would see that it doesn't help >> >> >> I also highly recommend you cherry-pick this very recent commit: >> net-next: 9d18562a2278 ("fq_codel: add batch ability to fq_codel_drop()") >> https://git.kernel.org/davem/net-next/c/9d18562a227 >> >> This should fix very high CPU usage in-case fq_codel goes into drop mode. >> The problem is that drop mode was considered rare, and implementation >> wise it was chosen to be more expensive (to save cycles on normal mode). >> Unfortunately is it easy to trigger with an UDP flood. Drop mode is >> especially expensive for smaller devices, as it scans a 4K big array, >> thus 64 cache misses for small devices! >> >> The fix is to allow drop-mode to bulk-drop more packets when entering >> drop-mode (default 64 bulk drop). That way we don't suddenly >> experience a significantly higher processing cost per packet, but >> instead can amortize this. > I haven't done the above cherry-pick patch & backport patch creation for > 4.4/4.1/3.18 yet - maybe if $dayjob permits time and no one else beats > me to it :-) > > Kevin >