Received: by 2002:a05:6358:5282:b0:b5:90e7:25cb with SMTP id g2csp2583444rwa; Mon, 22 Aug 2022 09:59:02 -0700 (PDT) X-Google-Smtp-Source: AA6agR7W7NE8oZpekHv+O3VyuaLmjnvc0haPCPt3qXhLNhf972RUvYdsY705YIYcvWwjtEjOI9OC X-Received: by 2002:a17:902:f54b:b0:16f:14e1:c484 with SMTP id h11-20020a170902f54b00b0016f14e1c484mr20817544plf.28.1661187541986; Mon, 22 Aug 2022 09:59:01 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1661187541; cv=none; d=google.com; s=arc-20160816; b=AXGf16csY5ZN6w3QgM/ujL1DYvX5rzDR8FpT1EYCvF1tybIDVmhtQZNA5RmNDUbeK3 xEnxH4BYH+4HMvKOLxdQwZnB0Wz6flrbZQpNZ0vI+HaVQ1b8FWIQifonddZ3AVWHhART s6nORpoK268znpVhUxrZFyzkmdNlRu5R7EqFBVSOPw8IJMHh1CRTvVGjJa/NeKCDz3Gd Jkx/1e7fW76jVGry2UgiWpL1tmjaXUT8ou+n1uMKcpt3YlYyuuLMPe4I3O2VMkVGaG7i uXnSCOory3olDxoH5DnyglkLer+XlR+SPxYEzB5hTr23Xn3MpaLTZpABO8FchFFG9no/ anUg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:subject:cc:to:from:date :dkim-signature; bh=lh2gyLBZm3bJ7aaQnR3WbZL1saCEt9bqeKdsvBcAsPc=; b=JZe0Va+uiQlr4mevv4qjQWXtm+IFo2P7kO+dgLoKPSXuKULgKaaq8rZcXHBtSl9X9w cVeq4t3Cb4DN5GUX8gTXKxJLfV+R/mXz/0ego+VD5kOUlJ7KA0fa9YlNVDE4BGKZ5bEk NYnJmA3DyvMf9KLxTLbO96WAt2Fe2StQ1SG3xObb+RdD4MF0AUK1128++YlULITNie1i 6m4IsKtm8LRGw2TYjApXFPlXxsRRAA5X3d68XWqudQgt8G+uB1ZbRdVz6tKX3dHpgP7M k5Yr0bCF+Lr93s1YAVX5xBmvJSGd8CUDkPjjK/5I2LysxzMxpv6Xg3agX43aHtCk6m4l gGrw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=ZuPN6YaD; 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=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id b2-20020a170902d50200b0016d6854674fsi14544940plg.385.2022.08.22.09.58.48; Mon, 22 Aug 2022 09:59:01 -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=@kernel.org header.s=k20201202 header.b=ZuPN6YaD; 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=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236053AbiHVQRo (ORCPT + 99 others); Mon, 22 Aug 2022 12:17:44 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:33192 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234679AbiHVQRm (ORCPT ); Mon, 22 Aug 2022 12:17:42 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 67D8633E2C; Mon, 22 Aug 2022 09:17:41 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 2BD58B80923; Mon, 22 Aug 2022 16:17:40 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 493EBC433C1; Mon, 22 Aug 2022 16:17:38 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1661185058; bh=mKS9e/kUYTrQTIQVgSXGZbMEtY2mtpS4FDMVJ2G5hmw=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=ZuPN6YaDp+AifescPV/BBlN9l96wSPcRJdLmXU63iV5LnFAkTCd+nXj7PjXTcsQtm j3sgomT7DIp0q9A6++5Y1dSF4BbCd2eSFuKaS4tU8HqRePQhb3jNj1EfUpobyymgV4 /f0EWQrNtfyT8dJvQ8zNPgcqPqtztx5uvS73KAFgSyRqCAxeRCA7NnxRkSCWIgzdYW n/PrTj9+NVVAKruizvGHiKE0iJlCwN3zolHSZ4VLvBdp+0WDXn4asPaQTc6p1+xLfg it/EwvWeFUEVCYdRuwMBTe4OJKrJdAc0LO6zlPtq2xfevP7kcM0jZaNnEijMPkP/Hc ogNv6/PHyenKA== Date: Mon, 22 Aug 2022 09:17:37 -0700 From: Jakub Kicinski To: Peilin Ye Cc: "David S. Miller" , Eric Dumazet , Paolo Abeni , Jonathan Corbet , Hideaki YOSHIFUJI , David Ahern , Jamal Hadi Salim , Cong Wang , Jiri Pirko , Peilin Ye , netdev@vger.kernel.org, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, Cong Wang , Stephen Hemminger , Dave Taht Subject: Re: [PATCH RFC v2 net-next 0/5] net: Qdisc backpressure infrastructure Message-ID: <20220822091737.4b870dbb@kernel.org> In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-7.1 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_HI, SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE 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, 22 Aug 2022 02:10:17 -0700 Peilin Ye wrote: > 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/ Similarly to Eric's comments on v1 I'm not seeing the clear motivation here. Modern high speed UDP users will have a CC in user space, back off and set transmission time on the packets. Could you describe your _actual_ use case / application in more detail?