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=-5.6 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,MENTIONS_GIT_HOSTING, SPF_HELO_NONE,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 B422AC3A5A9 for ; Mon, 4 May 2020 17:46:27 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 8ECD8206B8 for ; Mon, 4 May 2020 17:46:27 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="Rhfv2M39" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730371AbgEDRq0 (ORCPT ); Mon, 4 May 2020 13:46:26 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:54778 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-FAIL-OK-FAIL) by vger.kernel.org with ESMTP id S1729667AbgEDRq0 (ORCPT ); Mon, 4 May 2020 13:46:26 -0400 Received: from mail-ot1-x343.google.com (mail-ot1-x343.google.com [IPv6:2607:f8b0:4864:20::343]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id DEE56C061A0E for ; Mon, 4 May 2020 10:46:25 -0700 (PDT) Received: by mail-ot1-x343.google.com with SMTP id i27so9634285ota.7 for ; Mon, 04 May 2020 10:46:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=MjTATQ7LbIo2uv8z5dmlz6+xjDe7vQE3zrHBN2+KSWg=; b=Rhfv2M39Y7tql9Kp/HJaWMS4WYtH2AsqszK6HbGvnZbkFtJFi1bKu0VoXUQgqyNB31 Ij0ES9lkjZIbH0hRDTo6KlIDKf93unJ8JQNGFfYmEHC+PuCp3a876fmjM7xRKFeB4Far U026UFVAQtDeDvLQZuZnwIXgTXVXtpJlEaksEpI4z9c2Xh90yZuYPVxqTeiHprPSYeKD xLtARysWy24kI0l56jyyeDq9f7zsYCKajtJwEB8sbQX6pMWHoNG0eEFU4PsBUhgmznDq eYj7TJw6Moy2Snp5zEaV1NPITS54j5gbGfgUmLnSmVSF67JlSyQJUXaEZpbspy9D/gm8 Gjzw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=MjTATQ7LbIo2uv8z5dmlz6+xjDe7vQE3zrHBN2+KSWg=; b=TbUOl0db856bpB2eET0J8DfGHecq+k3tlOa+54ajiI4F1Xow/2hN9Qj2wTmBsVYTWs AJFk9SZ5Jq7LpgKOqFfxtuz/k5JTVvC+gVGdnEjE6Ih4Qi0ZdHFsYfx74vFdA4pAcRbI JYH2H0Kje118o31h7OwAwlsJg00dqK2/cLEWpaw47Z1Afv5C0Px8KWMe2h7w3BAqJOz4 yaGrI/o/Gg+RLSV/b7KKImF3YIGtlDNPWkeXFJvNwCB1JO7E1QYUEWW09dZy3iexkhmX L5gpseU0yeheiR9xpB2M6KdCyB6mU+OTDlpFF+km2ue2eIXz8kF7AmM3/adl8anl+gpY m0XQ== X-Gm-Message-State: AGi0PuYjLJZc6RQfVGKzNfUvzb8JYjub/T/2bzE24rUF0nLDBVxExQOD wuITHsn9vWRPni8AYW+NJ5vB3ux+37cwZmRPatQe1brq X-Google-Smtp-Source: APiQypJWz20W8ZlYaF2Od9GgRbf/GP72Yf3QBGWAHSTx8QDZxL+IuGsWSexEoEMM5L8N2/pP96Y9MlfycQy8p/v7Y8I= X-Received: by 2002:a05:6830:1409:: with SMTP id v9mr756599otp.189.1588614385286; Mon, 04 May 2020 10:46:25 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Cong Wang Date: Mon, 4 May 2020 10:46:13 -0700 Message-ID: Subject: Re: iproute2: tc deletion freezes whole server To: =?UTF-8?Q?V=C3=A1clav_Zindulka?= Cc: Linux Kernel Network Developers Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org On Thu, Apr 30, 2020 at 5:40 AM V=C3=A1clav Zindulka wrote: > > On Wed, Apr 15, 2020 at 5:01 PM V=C3=A1clav Zindulka > wrote: > > > > > The problem is actually more complicated than I thought, although= it > > > > > needs more work, below is the first pile of patches I have for yo= u to > > > > > test: > > > > > > > > > > https://github.com/congwang/linux/commits/qdisc_reset > > > > > > > > > > It is based on the latest net-next branch. Please let me know the= result. > > > > > > > > I have applied all the patches in your four commits to my custom 5.= 4.6 > > > > kernel source. There was no change in the amount of fq_codel_reset > > > > calls. Tested on ifb, RJ45 and SFP+ interfaces. > > > > > > It is true my patches do not reduce the number of fq_codel_reset() ca= lls, > > > they are intended to reduce the CPU time spent in each fq_codel_reset= (). > > > > > > Can you measure this? Note, you do not have to add your own printk() > > > any more, because my patches add a few tracepoints, especially for > > > qdisc_reset(). So you can obtain the time by checking the timestamps > > > of these trace events. Of course, you can also use perf trace like yo= u > > > did before. > > > > Sorry for delayed responses. We were moving to a new house so I didn't > > have much time to test it. I've measured your pile of patches applied > > vs unpatched kernel. Result is a little bit better, but it is only > > about 1s faster. Results are here. Do you need any additional reports > > or measurements of other interfaces? > > https://github.com/zvalcav/tc-kernel/tree/master/20200415 I've > > recompiled the kernel without printk which had some overhead too. > > Hello Cong, > > did you have any time to look at it further? I'm just asking since my > boss wants me to give him some verdict. I've started to study eBPF and > XDP in the meantime so we have an alternative in case there won't be a > solution to this problem. Sorry for the delay. I lost connection to my dev machine, I am trying to setup this on my own laptop. Regarding to your test result above, I think I saw some difference on my side, I have no idea why you didn't see any difference. Please let me collect the data once I setup the test environment shortly today. Thanks!