Received-SPF: pass (google.com: domain of linux-wireless-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
From:   Vinicius Costa Gomes <vinicius.gomes@intel.com>
To:     Jakub Kicinski <kuba@kernel.org>,
        Johannes Berg <johannes@sipsolutions.net>
Cc:     netdev@vger.kernel.org,
        Toke =?utf-8?Q?H=C3=B8iland-J=C3=B8rgensen?= <toke@toke.dk>,
        Avi Stern <avraham.stern@intel.com>,
        linux-wireless@vger.kernel.org
Subject: Re: taprio vs. wireless/mac80211
In-Reply-To: <20220824191500.6f4e3fb7@kernel.org>
References: <117aa7ded81af97c7440a9bfdcdf287de095c44f.camel@sipsolutions.net>
 <20220824191500.6f4e3fb7@kernel.org>
Date:   Fri, 26 Aug 2022 15:10:36 -0700
Message-ID: <87k06uk65f.fsf@intel.com>
MIME-Version: 1.0
Content-Type: text/plain
Precedence: bulk

Jakub Kicinski <kuba@kernel.org> writes:

> On Wed, 24 Aug 2022 23:50:18 +0200 Johannes Berg wrote:
>> Anyone have recommendations what we should do?
>
> Likely lack of sleep or intelligence on my side but I could not grok
> from the email what the stacking is, and what the goal is.
>
> Are you putting taprio inside mac80211, or leaving it at the netdev
> layer but taking the fq/codel out?

My read was that they want to do something with taprio with wireless
devices and were hit by the current limitation that taprio only supports
multiqueue interfaces.

The fq/codel part is that, as far as I know, there's already a fq/codel
implementation inside mac80211.

The stacking seems to be that packets would be scheduled by taprio and
then by the scheduler inside mac80211 (fq/codel based?).


Cheers,
-- 
Vinicius