From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-it0-x244.google.com (mail-it0-x244.google.com [IPv6:2607:f8b0:4001:c0b::244]) (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 151A43B2B0 for ; Sun, 12 Jun 2016 13:48:57 -0400 (EDT) Received: by mail-it0-x244.google.com with SMTP id i6so4821841ith.0 for ; Sun, 12 Jun 2016 10:48:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:subject:from:to:cc:date:in-reply-to:references :mime-version:content-transfer-encoding; bh=vOzCnoabjSrDK4Ws9RNE3PYYDRj9D4iG6lKK3WCNQw4=; b=RKK7VPuMjBQbAhomkmxlPY2F3yiA5Z05ZFNQv29Xwy+8/Lv6Eq+rP+3v0ZVMweRk+q EVSmsgl/1BlLHI1NbDu7ZIFFQDsqkyDtmlVcMPUSk1JjCUKmwnhVptCYEfCEUaqrwTee cgbLS9h+frkpsTFYWrQ6t+JPFyLzkBVOKUd50xR2JjtAXp12cycUfPBNB4Vbwxcw+nJ+ grpMFDLkKt6JJlApyQ4nCA/BCYYCaoyJ5iJaYSP199jtRjA+ygs1yMm6s8gBzmdSDf6V axVYADMNqA99otknHTv1DkxTPHr4Du6MEMu9lku06nwf4Uj5wLookoT7R862xbN8zINp wpTA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:subject:from:to:cc:date:in-reply-to :references:mime-version:content-transfer-encoding; bh=vOzCnoabjSrDK4Ws9RNE3PYYDRj9D4iG6lKK3WCNQw4=; b=G4LNMV1TqqXs1WCw1dwfNZDDNoFKF5K2qM6sKo77BpPJIuDGgrJHm9P01Z+5o9PTGk ocmMrOURRk55GydO7wHQlv8v69qXxG+0ZEfSdGQw19/VQezsRYswsy+IDUYjSJgFSEoP Vq0SWtkxLAS52SadTf9cYG8sCO8OinakdZnzdiypJexKH4hTANwVGQI3CCnax5DHDHt+ w2R2jl1Z2bz7QF8vXmo6rHs0anH2ogcbRU/V/vjw/RWCvwb6GkvMJqkfHJaFCkWV/Tev M8TZcGoMFusHQuv9i6gopBRIOj8Elit9hIV3vJ5N49+mN9DHh0qPHuQVPxkfrrToCS7B RkvQ== X-Gm-Message-State: ALyK8tLWGxD8hx/f8p9tEKKTDwyMuQZ7HAfsQzqUvkh26cJgPL+f2zlzCX9q+2P84AnAfQ== X-Received: by 10.36.149.215 with SMTP id m206mr12749511itd.20.1465753736545; Sun, 12 Jun 2016 10:48:56 -0700 (PDT) Received: from [172.26.50.149] ([172.26.50.149]) by smtp.googlemail.com with ESMTPSA id k20sm10428465iok.14.2016.06.12.10.48.55 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 12 Jun 2016 10:48:55 -0700 (PDT) Message-ID: <1465753733.7945.85.camel@edumazet-glaptop3.roam.corp.google.com> From: Eric Dumazet To: Dave Taht Cc: Jonathan Morton , cake@lists.bufferbloat.net Date: Sun, 12 Jun 2016 10:48:53 -0700 In-Reply-To: References: <5756ADEC.9070305@darbyshire-bryant.me.uk> <8EE35B4F-5C28-41C7-8795-93A6F606B3A8@gmail.com> <5756E2CA.2020700@darbyshire-bryant.me.uk> <575BD5D0.4060702@darbyshire-bryant.me.uk> <98AFD8C3-2343-4B8B-BFB0-6F877161A039@gmail.com> <1465749085.7945.81.camel@edumazet-glaptop3.roam.corp.google.com> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.10.4-0ubuntu2 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Subject: Re: [Cake] Possible BUG - parent backlog incorrectly updated in case of NET_XMIT_CN 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: Sun, 12 Jun 2016 17:48:57 -0000 On Sun, 2016-06-12 at 09:40 -0700, Dave Taht wrote: > Eric: > > Quick side question (from trying to understand the qdisc locking fixes > you recently landed in net-next) > > In the sqm-scripts, we are usually in a position where we are doing > both inbound and outbound rate limiting (htb + fq_codel or cake). We > typically run out of cpu or have mis-behavior on the inbound side, and > the cpu bottleneck appears to be in ksoftirqd. > > A) In my failing to make sense of all the dialog around these patches > ( https://lwn.net/Articles/687617/ ), it sounds like this (inbound > and outbound) processing are still locked to a single thread, > essentially? Om a router, these discussions should not matter really, since the workload is about receiving/sending packets without user space intervention (well... I do hope this !) > > B) But you have eliminated lot of overhead in basic qdisc processing > to much cpu benefit and we should consider backporting these changes > to lede/openwrt (4.4)? It is possible that my recent patches avoiding the throttled bit manipulation might help. I measured between 7% and 8% change in my tests on x86 with HTB qdisc. e69f73bfecb0178ae6bd20eb778211739cd71fab Merge branch 'remove-qdisc-throttle' 45f50bed1d808794e514e9eed0e579a8756ce2ba net_sched: remove generic throttled management 42117927cab5a13192ecc227bea19da5059ffc6c net_sched: netem: remove qdisc_is_throttled() use cca605dd4b3b2bfa381250b7dbbe16b124916f24 net_sched: cbq: remove a flaky use of qdisc_is_throttled() 8fe6a79fb8088a759b3dc57eb641fc3183ad72b8 net_sched: sch_plug: use a private throttled status