From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-1.1 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_PASS autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id EB86DC43381 for ; Wed, 27 Feb 2019 00:56:54 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id B6876218D0 for ; Wed, 27 Feb 2019 00:56:54 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="JLxjwDoi" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729246AbfB0A4x (ORCPT ); Tue, 26 Feb 2019 19:56:53 -0500 Received: from mail-pl1-f175.google.com ([209.85.214.175]:35198 "EHLO mail-pl1-f175.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727998AbfB0A4x (ORCPT ); Tue, 26 Feb 2019 19:56:53 -0500 Received: by mail-pl1-f175.google.com with SMTP id p19so7101417plo.2 for ; Tue, 26 Feb 2019 16:56:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=3aK8T2vbSrhkovHl0gBIPFBVvIxUsewEB5dQ54XWdZs=; b=JLxjwDoimTpteNCWZsAacdpkneN0FQTyCoNKz8k3V84xmC/4jq9xmx12Ljlvtsjb7+ EHDqfPboJOsunuVy90dcy2qKAk8xHPaC2YQh2A7VADkcgxSV8SOgSq18DhY5v4ODoCYD nvUxzdNJ4XHsaxm7bbVTOE4tYgFoiLAe+sLMbedadWoV2fsA1QGUhMDRjevo4GwnY7Gu vDVyl3WhWkY2JHWv4Mykq6e5jAnJLNFvd7hX+ub5aVUYC4zS5UgpR769Fn/PABxRF4Bw kW6oGTTfqZI4N4bWdlJWcvw69mEMjf4iRtWxtpwHQUTAy1nqxio2PGm4otQ5VFvwG7BR 7UgA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=3aK8T2vbSrhkovHl0gBIPFBVvIxUsewEB5dQ54XWdZs=; b=rqPwadCOZXKtSJPQQaS5H0dS7reyA3Ww52XEdA90Q51raOGfTys4qdqRmQS2xpk5Dt ZZ1DIUb0FnPD6J/SkyiJtWSoJExt6U5S6FT3t7zhOBn7qJ3xhgBfjN2pAA1QAFjW4hks G6o4k5GyA+wb1i15fauTkB0NjOgviRiYzn5pMJ+94J77uL7Wf5e38eFXNBiq/shHnIin NfMx8tsQuQOM/QXDBNobfWuxHLm52k9kSWZjpjd5/MxABNyXNI+Pv0idYjPvgXN4oz12 3J9flXplKkMkI/gLZ4cPqLdjQIVmg0v9kIQuLuRk0Z6kK/fMj6739nAvjjQkh1b8qeyl onYg== X-Gm-Message-State: AHQUAuZJuEy6ur8OmHDldDOSklQ5NdzM0o1zGFx76zPhc01pP1Jc1COI pgRHDrmG3aGMyhMXEjUxEbI= X-Google-Smtp-Source: AHgI3IZmgbS/3fWf509ltEgFaoxwDJOCe+HVSIBV/KvCtqoJSIQ7rgYEFQ2ikh2m9IaeedBmB0+DHA== X-Received: by 2002:a17:902:6b49:: with SMTP id g9mr29470838plt.291.1551229012641; Tue, 26 Feb 2019 16:56:52 -0800 (PST) Received: from [192.168.86.235] (c-73-241-150-70.hsd1.ca.comcast.net. [73.241.150.70]) by smtp.gmail.com with ESMTPSA id g3sm18050441pgg.41.2019.02.26.16.56.50 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 26 Feb 2019 16:56:50 -0800 (PST) Subject: Re: [BUG] net/sched : qlen can not really be per cpu ? To: Cong Wang Cc: John Fastabend , Networking , Jamal Hadi Salim , Jiri Pirko References: <5fb87db3-d5bd-714b-213d-6821f4bf37da@gmail.com> From: Eric Dumazet Message-ID: Date: Tue, 26 Feb 2019 16:56:49 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org On 02/26/2019 03:51 PM, Cong Wang wrote: > On Tue, Feb 26, 2019 at 3:19 PM Eric Dumazet wrote: >> >> >> >> On 02/25/2019 10:42 PM, Eric Dumazet wrote: >>> HTB + pfifo_fast as a leaf qdisc hits badly the following warning in htb_activate() : >>> >>> WARN_ON(cl->level || !cl->leaf.q || !cl->leaf.q->q.qlen); >>> >>> This is because pfifo_fast does not update sch->q.qlen, but per cpu counters. >>> So cl->leaf.q->q.qlen is zero. >>> >>> HFSC, CBQ, DRR, QFQ have the same problem. >>> >>> Any ideas how we can fix this ? >> >> What about something simple for stable ? >> ( I yet have to boot/test this ) > > Is merely updating qlen sufficient for fixing it? > > I thought it is because of the lack of qdisc_tree_reduce_backlog() > in pfifo_fast. It does not seem to be the qdisc_tree_reduce_backlog() thing. HTB, HFSC, CBQ, DRR, QFQ only peek at their children 'qlen' to decide if there is at least one packet in them. The backlog is only reported for dumps, but the actual backlog value is not used in data path.