Received-SPF: pass (google.com: best guess record for domain of linux-wireless-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Message-ID: <bf9053f2675959f966453b999b71f9446ad8eba2.camel@sipsolutions.net>
Subject: Re: [PATCH 5/5] mac80211: set NETIF_F_LLTX when using intermediate
 tx queues
From:   Johannes Berg <johannes@sipsolutions.net>
To:     Herbert Xu <herbert@gondor.apana.org.au>
Cc:     Toke =?ISO-8859-1?Q?H=F8iland-J=F8rgensen?= <toke@redhat.com>,
        Arend Van Spriel <arend.vanspriel@broadcom.com>,
        Felix Fietkau <nbd@nbd.name>, linux-wireless@vger.kernel.org,
        Eric Dumazet <eric.dumazet@gmail.com>, netdev@vger.kernel.org
Date:   Thu, 25 Apr 2019 10:49:42 +0200
In-Reply-To: <20190425084428.poni4y7mqox5up5t@gondor.apana.org.au>
References: <95f86cf69dee05a176625925657cf0df0e97b5c9.camel@sipsolutions.net>
         <20190416093707.dtlwcmitzqopaeaw@gondor.apana.org.au>
         <e4c1a3ca0c0c160b7c271ab83deebcf096f38497.camel@sipsolutions.net>
         <20190416131346.u2uolljlrd5t2jro@gondor.apana.org.au>
         <87wojut7f7.fsf@toke.dk>
         <20190417033834.ep6t7r6ttvjek5g7@gondor.apana.org.au>
         <87tvexrnxm.fsf@toke.dk>
         <99da695257304d32b65e2db8b7ada06759087c90.camel@sipsolutions.net>
         <20190425083558.p3kqodaawr2jcfhr@gondor.apana.org.au>
         <0190c32f3d861d9d7a783090653645c5ae3a7fa3.camel@sipsolutions.net>
         <20190425084428.poni4y7mqox5up5t@gondor.apana.org.au>
Content-Type: text/plain; charset="UTF-8"
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Sender: linux-wireless-owner@vger.kernel.org
Precedence: bulk

On Thu, 2019-04-25 at 16:44 +0800, Herbert Xu wrote:
> On Thu, Apr 25, 2019 at 10:39:52AM +0200, Johannes Berg wrote:
> > 
> > Yes, that's what I meant, it can only ever return NET_XMIT_SUCCESS or
> > NET_XMIT_CN. This will not trigger the code you mentioned before though.
> 
> You are right that it does not.  However, the fact that this
> congestion indication is lost is a bug rather than a feature.

You can argue that way, I guess.

However, *any* queue management algorithm that doesn't *solely* employ
tail drops will necessarily behave this way.

I would argue that you get better queue management if you don't solely
rely on tail drops, so I'd rather pick better queue management than this
(relatively obscure) congestion notification. The more commonly relevant
socket buffer size will work for both.

johannes