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 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 90345ECAAD5 for ; Sat, 27 Aug 2022 01:06:48 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232233AbiH0BGr (ORCPT ); Fri, 26 Aug 2022 21:06:47 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:43516 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231181AbiH0BGp (ORCPT ); Fri, 26 Aug 2022 21:06:45 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 9E9C7A74FE for ; Fri, 26 Aug 2022 18:06:43 -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 dfw.source.kernel.org (Postfix) with ESMTPS id 3DCCA61BD2 for ; Sat, 27 Aug 2022 01:06:43 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 80369C433D6; Sat, 27 Aug 2022 01:06:42 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1661562402; bh=A6WMCLvtYG4I6W0kBFnzIXcSzGSd5iQnmn6Bo02JRKA=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=WrcuI2KqJjMueBacfZ1tAtfuzJU/FZN5MY+Jyd3Cwp3xhqyi/AREcyxkLjwp+aL3E 5kedYleaTlPZB1t29Gtp0KlyfxsfUWgVFDvcQt+kTPLVeMURLF+WRcbIoRZOirp3kt 07u6owmdSaMpluD4lgqTnTGYfYkpcW7WymcL/RQ2D5/RqgAuQGNX9xXNa13mue5NbL J72P3tVVU4N55DfO2wdQKwzbubwjhigks+0o/4zXZK55qmE0yZYuRawxx5lHtqNZy/ PHdkm7xuqjm/Gkij0Jstk+KmmKvMtGd+AjhneKFMXb9ahxuSamKBCKSWi02AsZmPJx LB9m8vAm44zNw== Date: Fri, 26 Aug 2022 18:06:41 -0700 From: Jakub Kicinski To: Thorsten Glaser Cc: netdev@vger.kernel.org Subject: Re: inter-qdisc communication? Message-ID: <20220826180641.1e856c1d@kernel.org> In-Reply-To: <49bb3aa4-a6d0-7f38-19eb-37f270443e7e@tarent.de> References: <5aea96db-9248-6cff-d985-d4cd91a429@tarent.de> <20220826170632.4c975f21@kernel.org> <49bb3aa4-a6d0-7f38-19eb-37f270443e7e@tarent.de> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org On Sat, 27 Aug 2022 02:45:02 +0200 (CEST) Thorsten Glaser wrote: > > How do you add latency on ingress? =F0=9F=A4=94=20 > > The ingress qdisc is just a stub to hook classifiers/actions. =20 >=20 > Oh, damn. Then, I guess, I=E2=80=99ll have to do that on egress on > the other interface, which makes it at least symmetric for > passing traffic but catch not the set of traffic it should. > Especially not the traffic terminating locally. Meh. >=20 > The question remains the same, just the use case magically > mutated under me. >=20 > (Maybe if there were documentation like an intro to qdisc > writing like I asked for already, I=E2=80=99d have known that.) These days the recommendation for adding workload specific sauce=20 at the qdisc layer is to use the fq qdisc (mq + fq if you have=20 a multi queue device) and add a BPF program on top (cls-bpf) which sets transmission times for each packet. Obviously you can still write a qdisc if you wish or your needs=20 are sufficiently hardcore. On the docs, nothing official AFAIK, if it doesn't pop up in=20 the first two pages of Google results it probably doesn't exist :(