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=-1.0 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_PASS,URIBL_BLOCKED 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 1C509C10F12 for ; Wed, 17 Apr 2019 08:36:07 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id E90FC20835 for ; Wed, 17 Apr 2019 08:36:06 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1731363AbfDQIgF convert rfc822-to-8bit (ORCPT ); Wed, 17 Apr 2019 04:36:05 -0400 Received: from mail-ed1-f67.google.com ([209.85.208.67]:46637 "EHLO mail-ed1-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727087AbfDQIgF (ORCPT ); Wed, 17 Apr 2019 04:36:05 -0400 Received: by mail-ed1-f67.google.com with SMTP id d1so20211537edd.13 for ; Wed, 17 Apr 2019 01:36:04 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:in-reply-to:references:date :message-id:mime-version:content-transfer-encoding; bh=VYXPLMzS2L3NEuIvF9Zqlc1sEufo5VsP3GxfWStSls8=; b=orJr9ZscprdbCmGkoBZmGEeZCqPgLH1X7UQ4XpjmemZsCHfDySX0XWncCmd3SVuuqV JxVvJyQ012otBTk+42IXTaqOUNWlf84woZ16scukstQzqen5wl2d9kXQZnswvM+kpKFB dsYfIpS0Vn7D32HJQ56A/rss4tV30Ly8uMnH4dv5+Z4dgcNkG6zro4Th3UqQDR79oL2m 7LQPBSuQa5BoXpJIgM1qerAClVruPtbxPanr7Hg0B577stUBgsZpL3pISZeXBZNqYRQ4 qRpjRr5E7IF9DVwyYzQmBQxP1S8DFxcvPMoOdWGgKZzDx8w+AfLUpZDzkpwx55y1HWYU rtiQ== X-Gm-Message-State: APjAAAUgMM/BqcBVlrDkU8YM+Erhbu2PH5JA8QIdpa0YH2OLgj1C4nLt MuEwZ/PxuWRqU53Mvyu2D5fxWA== X-Google-Smtp-Source: APXvYqxh0PhqZpa6jlQPf4fzPGwI/6lognZO7+QlqTeirQgTEz+ZDQwQr/HJHFoK20EYOM1QwrAEGQ== X-Received: by 2002:a17:906:8247:: with SMTP id f7mr45679482ejx.216.1555490163423; Wed, 17 Apr 2019 01:36:03 -0700 (PDT) Received: from alrua-x1.borgediget.toke.dk (borgediget.toke.dk. [85.204.121.218]) by smtp.gmail.com with ESMTPSA id i9sm6157988edk.56.2019.04.17.01.36.02 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Wed, 17 Apr 2019 01:36:02 -0700 (PDT) Received: by alrua-x1.borgediget.toke.dk (Postfix, from userid 1000) id D589B1800E8; Wed, 17 Apr 2019 09:28:51 +0100 (+01) From: Toke =?utf-8?Q?H=C3=B8iland-J=C3=B8rgensen?= To: Herbert Xu Cc: Johannes Berg , Arend Van Spriel , Felix Fietkau , linux-wireless@vger.kernel.org, Eric Dumazet , netdev@vger.kernel.org Subject: Re: [PATCH 5/5] mac80211: set NETIF_F_LLTX when using intermediate tx queues In-Reply-To: <20190417021101.5a32gox2ivbcgsbp@gondor.apana.org.au> References: <773e4dff-29fd-22b4-e4bc-cd5a94c66dc2@broadcom.com> <20190416074444.pdubbh6fbibdnhi7@gondor.apana.org.au> <73b18131-2777-da5c-a6ee-9d9b3e13cd06@broadcom.com> <20190416083636.5ttvezqyhzr2worg@gondor.apana.org.au> <87ef62uwfm.fsf@toke.dk> <95f86cf69dee05a176625925657cf0df0e97b5c9.camel@sipsolutions.net> <20190416093707.dtlwcmitzqopaeaw@gondor.apana.org.au> <8736miuv1x.fsf@toke.dk> <20190417021101.5a32gox2ivbcgsbp@gondor.apana.org.au> X-Clacks-Overhead: GNU Terry Pratchett Date: Wed, 17 Apr 2019 09:28:51 +0100 Message-ID: <875zrdt4qk.fsf@toke.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8BIT Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org Herbert Xu writes: > On Tue, Apr 16, 2019 at 11:02:50AM +0100, Toke Høiland-Jørgensen wrote: >> >> As explained at great length here: >> https://www.usenix.org/conference/atc17/technical-sessions/presentation/hoilan-jorgesen >> (you already know that of course, Johannes) > > I can understand that wireless needs its own queueing scheme, but it > still seems wrong to place that under net/mac80211 as opposed to > having it as a first-class citizen under net/sched. This is because we need to resolve the MAC-layer destination station (or rather, TID) and tie the queueing to that, because of aggregation. We also use the queueing structure for scheduling stations to achieve airtime fairness. Both of these would be decidedly non-trivial to pull up to the qdisc layer. Rather, having them in mac80211 means drivers don't need to do their own ad-hoc queueing (which was the case before, leading extra bufferbloat). Most of the actual queueing structure code lives in include/net/fq_impl.h, though, so it's not actually that mac80211-specific. I've been thinking about porting the relevant qdiscs to use the same code, but I'm not sure that it's worth the trouble. -Toke