Received: by 2002:a05:6358:5282:b0:b5:90e7:25cb with SMTP id g2csp2555729rwa; Mon, 22 Aug 2022 09:29:49 -0700 (PDT) X-Google-Smtp-Source: AA6agR7jbwFTdkt1Ji/SW/5PgIS3/SMfMGh2jhmw1AyDO+oTGPLEMUlLsEbBpocyiQbveVBB7/w2 X-Received: by 2002:a05:6402:2b8d:b0:43a:5410:a9fc with SMTP id fj13-20020a0564022b8d00b0043a5410a9fcmr17207150edb.99.1661185789204; Mon, 22 Aug 2022 09:29:49 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1661185789; cv=none; d=google.com; s=arc-20160816; b=yxD6co5FcnnRRreyKxzJetS905NRgOYrd54gCVcbl4diNC7UvLG7ckjWq8Gf1BcR/s 1ctx9jd2KOtz5ISW9+35YKtm5dD1hYlX5cdOesa02bircXXPrxzknevx94D7V4kyft5v rpxB1LzKavILpqKB4LDqBtM63HGBC0IEUwsktHQLSBi1pi7DHLB3bIstYVAplKv+nciz /u+74h2bsWdkK+VSxa3bxZcBMhMe3GGDl/Ib8fptaYXnzHCikagd6EK3wFVawwsoUwk5 CcfvdMoMW0A6ZvX0EzST5bVOXLAwwcunhX2YcPuMvE7Pw0uIj2HIrBuMtl2IsAAzVBO7 8Q5w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=zBnLNnOuEm5lJhwtbUOYYe47b/c/6C+EcZMDaQGtBP4=; b=EJFAfbhYn+DLnaFYvREkNuvf65NGdCE3DfisipPAO82QSso2i0bD8Ndib/bb+2TkoH eOiUzzVlfzBHpJtV02X3lQCtGrvGB7Ki/nf80CTbY+k6kTxxyx9apYfp8GVl8/iEkDqH kYSjK4y9Kv3X6A0+YG9rzYwt4HSkeQIBQVBInJRY6us68wstN4S6l/F47TTsC9oqp2DD iHqr04yV/YBdrkKZn26QhZN5ZrhbgHt85WEghbWg/jKnLEX7e3ME8ZL3ffOs/Xv4u9qK pwbrx20VwCPIZnb7yTVQkt4wvnoXFEXQFYYvaed99j3QA+0zjyMyf900HAED6wrTmPHJ wf+g== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b="pyq/6kJ6"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id g13-20020aa7d1cd000000b004436bac7e37si8422693edp.596.2022.08.22.09.29.21; Mon, 22 Aug 2022 09:29:49 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b="pyq/6kJ6"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236730AbiHVQWx (ORCPT + 99 others); Mon, 22 Aug 2022 12:22:53 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:39814 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235888AbiHVQWw (ORCPT ); Mon, 22 Aug 2022 12:22:52 -0400 Received: from mail-yw1-x1129.google.com (mail-yw1-x1129.google.com [IPv6:2607:f8b0:4864:20::1129]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 6D0A23F330 for ; Mon, 22 Aug 2022 09:22:51 -0700 (PDT) Received: by mail-yw1-x1129.google.com with SMTP id 00721157ae682-3246910dac3so307489917b3.12 for ; Mon, 22 Aug 2022 09:22:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc; bh=zBnLNnOuEm5lJhwtbUOYYe47b/c/6C+EcZMDaQGtBP4=; b=pyq/6kJ6DsGWQlpt2s0VXNeG1rxbZvr1f8onglt28Gp3w96/d34SrxrZQKd8GAMLm+ msURTCw8d+HAGTCxXo+r1oPnP78lH3o/XZjrXAJql3eo/TWCz7OLc+KEwApPb0UJ7Hpl FNm3OiQC2PTNuqZz8hzOyFowdGYaSR6FkBfiC3dfAhvA5oImQffN/izIYDhbbUtANHEn 3QyD1kGFtLsm3q0e56fiqMtObmqSmqyVA3koNFPZ1gFzMjjkRg1073VPTHRa79YYJ50A L0VFjNfjcflJ6KITQLbLCagavJ31oWZyTuDrDWqMfEggK36BvBoMpUHUXSYo98tozrvY IK2Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc; bh=zBnLNnOuEm5lJhwtbUOYYe47b/c/6C+EcZMDaQGtBP4=; b=oYudKQ5vgMETebAU42FfsEL6hSJ7xCqAoucaMa84WsjCf1g96U+ieJQaatFqsf9vgB fy0LobECYKV5VqIS5DaGR9iIKTVrPW7C+V07hxJ4GUpJdK3xKpnfOtv3wapC+l/h7vGN P9eO/wtuLUp0zWojf34NIRfz18pbkWNjaLCknGg0rqEQglb+YWABBL+BJoXGzEiNflbv qZNtCRFoBAb+/dPMyoXwlHMIkKdhtnATSdA6TsihIAe06Ihq1I0YlN0glxcRN0ecI+jU aA5aBETts58Z1/5dJl1IWNpFMrksS/Psv0FfTbEwNr1fKJUdvNDtAXrfaSi1nA44mTBF CGXw== X-Gm-Message-State: ACgBeo1nJVsOrmgdGkZmd3mSVsrRSB5yRFa5uY+oNmQrIYrmcF2RUGSw 9/iurh+yJU71sddju93KFX1gTIyp3ojMWRzgnh+Ivw== X-Received: by 2002:a25:5091:0:b0:690:1f61:a7c9 with SMTP id e139-20020a255091000000b006901f61a7c9mr20337108ybb.55.1661185370392; Mon, 22 Aug 2022 09:22:50 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Eric Dumazet Date: Mon, 22 Aug 2022 09:22:39 -0700 Message-ID: Subject: Re: [PATCH RFC v2 net-next 0/5] net: Qdisc backpressure infrastructure To: Peilin Ye Cc: "David S. Miller" , Jakub Kicinski , Paolo Abeni , Jonathan Corbet , Hideaki YOSHIFUJI , David Ahern , Jamal Hadi Salim , Cong Wang , Jiri Pirko , Peilin Ye , netdev , "open list:DOCUMENTATION" , LKML , Cong Wang , Stephen Hemminger , Dave Taht Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-17.6 required=5.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF, ENV_AND_HDR_SPF_MATCH,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS, T_SCC_BODY_TEXT_LINE,USER_IN_DEF_DKIM_WL,USER_IN_DEF_SPF_WL autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Aug 22, 2022 at 2:10 AM Peilin Ye wrote: > > From: Peilin Ye > > Hi all, > > Currently sockets (especially UDP ones) can drop a lot of packets at TC > egress when rate limited by shaper Qdiscs like HTB. This patchset series > tries to solve this by introducing a Qdisc backpressure mechanism. > > RFC v1 [1] used a throttle & unthrottle approach, which introduced several > issues, including a thundering herd problem and a socket reference count > issue [2]. This RFC v2 uses a different approach to avoid those issues: > > 1. When a shaper Qdisc drops a packet that belongs to a local socket due > to TC egress congestion, we make part of the socket's sndbuf > temporarily unavailable, so it sends slower. > > 2. Later, when TC egress becomes idle again, we gradually recover the > socket's sndbuf back to normal. Patch 2 implements this step using a > timer for UDP sockets. > > The thundering herd problem is avoided, since we no longer wake up all > throttled sockets at the same time in qdisc_watchdog(). The socket > reference count issue is also avoided, since we no longer maintain socket > list on Qdisc. > > Performance is better than RFC v1. There is one concern about fairness > between flows for TBF Qdisc, which could be solved by using a SFQ inner > Qdisc. > > Please see the individual patches for details and numbers. Any comments, > suggestions would be much appreciated. Thanks! > > [1] https://lore.kernel.org/netdev/cover.1651800598.git.peilin.ye@bytedance.com/ > [2] https://lore.kernel.org/netdev/20220506133111.1d4bebf3@hermes.local/ > > Peilin Ye (5): > net: Introduce Qdisc backpressure infrastructure > net/udp: Implement Qdisc backpressure algorithm > net/sched: sch_tbf: Use Qdisc backpressure infrastructure > net/sched: sch_htb: Use Qdisc backpressure infrastructure > net/sched: sch_cbq: Use Qdisc backpressure infrastructure > I think the whole idea is wrong. Packet schedulers can be remote (offloaded, or on another box) The idea of going back to socket level from a packet scheduler should really be a last resort. Issue of having UDP sockets being able to flood a network is tough, I am not sure the core networking stack should pretend it can solve the issue. Note that FQ based packet schedulers can also help already.