Received: by 2002:a05:6a10:c7c6:0:0:0:0 with SMTP id h6csp2246617pxy; Tue, 3 Aug 2021 01:10:42 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyKH193qLEFHQERUO6GUFO1yb0QGguRQtUAIhnVWG9OB8xZYyZs3I9pTtxSK4fFTquAH0ho X-Received: by 2002:a02:b718:: with SMTP id g24mr7364615jam.72.1627978241865; Tue, 03 Aug 2021 01:10:41 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1627978241; cv=none; d=google.com; s=arc-20160816; b=b+RCh/4bHbhv16+kIqVsF3YdUpxuy0+iwT+C9HFjB26wqZExJYmqwnZeh1AXcbq9pj WbCz1797/KjTwscy08WbBTTqcxrCQ3qhPh/wPcd3ERAlkPSxsNBFep71Ieg9dn6LkD46 Xm2bPPIzbE9elbRBCjFgcvkFsPyFGAT4XI9WCeDt+ejm+U36IMHkXRmOTGFc/alTNav5 5zAkAq9fvVuorCbWkVQ2YdsURIWtean8/XQrnI9lZZdBAK8GQDQ95qIeU9KzDS8DpxMb +ZOcKQXOnfelB/cpTelPEsPYSJhTlEYBNnEEdmvVKJc03GlKJc9c7RIT1qkIah44r6j5 2aCw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:content-language :in-reply-to:mime-version:user-agent:date:message-id:from:references :cc:to:subject; bh=bx/6TY2+4VmLqGOuzfn92/lvL8SAmOP1UA7cFzdPoY8=; b=af+g5MXh0eQak5PxIUppc751mmrLcTUZn2Im3pxR77wO1Ep95PizqkA1PdFvShUi1H FzhFuVxqVVJRRInvu4Uenb4NJwCBl7JP5iBZZ3AO82HibK/YJ49zc7EHbvAdXUcF2V9Y 5OI0ysRbsKo0HC7kGZyxBmn1NxViI5Udk6iI7xcbd9aIFDgLG0nWJjRZL2NRT1Azq1pS Eqpz/bk6knUjFcVrhkx3/Xmltjtu7tl39NwaBC7Ow4PaFx2DtPPLgkPDeVNImG8qGt/p L2infUFR9djPcTNiHnNMjUX7ox9CNykgvL414R8YPRpAMqNbfYwYoAi/KWmr0LEvROZ6 31Lg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id 10si14471841ilq.145.2021.08.03.01.10.26; Tue, 03 Aug 2021 01:10:41 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234559AbhHCIJo (ORCPT + 99 others); Tue, 3 Aug 2021 04:09:44 -0400 Received: from www62.your-server.de ([213.133.104.62]:44598 "EHLO www62.your-server.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234455AbhHCIJT (ORCPT ); Tue, 3 Aug 2021 04:09:19 -0400 Received: from sslproxy06.your-server.de ([78.46.172.3]) by www62.your-server.de with esmtpsa (TLSv1.3:TLS_AES_256_GCM_SHA384:256) (Exim 4.92.3) (envelope-from ) id 1mApTi-0001E5-4G; Tue, 03 Aug 2021 10:08:46 +0200 Received: from [85.5.47.65] (helo=linux.home) by sslproxy06.your-server.de with esmtpsa (TLSv1.3:TLS_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1mApTh-000HvD-J6; Tue, 03 Aug 2021 10:08:45 +0200 Subject: Re: [PATCH net-next 1/2] net/sched: sch_ingress: Support clsact egress mini-Qdisc option To: Cong Wang Cc: Peilin Ye , Jamal Hadi Salim , Jiri Pirko , "David S. Miller" , Jakub Kicinski , Linux Kernel Network Developers , LKML , Cong Wang , Peilin Ye , Alexei Starovoitov , John Fastabend References: <1931ca440b47344fe357d5438aeab4b439943d10.1627936393.git.peilin.ye@bytedance.com> <672e6f13-bf58-d542-6712-e6f803286373@iogearbox.net> From: Daniel Borkmann Message-ID: Date: Tue, 3 Aug 2021 10:08:40 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.7.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Authenticated-Sender: daniel@iogearbox.net X-Virus-Scanned: Clear (ClamAV 0.103.2/26251/Mon Aug 2 10:18:34 2021) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 8/3/21 2:08 AM, Cong Wang wrote: > On Mon, Aug 2, 2021 at 2:11 PM Daniel Borkmann wrote: >> >> NAK, just use clsact qdisc in the first place which has both ingress and egress >> support instead of adding such hack. You already need to change your scripts for >> clsact-on, so just swap 'tc qdisc add dev eth0 ingress' to 'tc qdisc add dev eth0 >> clsact' w/o needing to change kernel. > > If we were able to change the "script" as easily as you described, > you would not even see such a patch. The fact is it is not under > our control, the most we can do is change the qdisc after it is > created by the "script", ideally without interfering its traffic, > hence we have such a patch. > > (BTW, it is actually not a script, it is a cloud platform.) Sigh, so you're trying to solve a non-technical issue with one cloud provider by taking a detour for unnecessarily extending the kernel instead with functionality that already exists in another qdisc (and potentially waiting few years until they eventually upgrade). I presume Bytedance should be a big enough entity to make a case for that provider to change it. After all swapping ingress with clsact for such script is completely transparent and there is nothing that would break. (Fwiw, from all the major cloud providers we have never seen such issue in our deployments.) Thanks, Daniel