From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-x236.google.com (mail-wm0-x236.google.com [IPv6:2a00:1450:400c:c09::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 2B9213B25D for ; Tue, 23 Aug 2016 04:52:55 -0400 (EDT) Received: by mail-wm0-x236.google.com with SMTP id f65so153170380wmi.0 for ; Tue, 23 Aug 2016 01:52:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=broadcom.com; s=google; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=7ka4URs0CTGU3VgKnph52Sd8bIRvP/WyTfE635VTfRQ=; b=ab1wNKnRXoxzhO1UwgBhcamwof8qCO8ULw04Yy4Cx66eSgK8nr7KfBZWL8n2i8vLEV FJOet5XEbP1L9fghJHxnCUOrgzB/XVgdYNWDBAvSAi/DZargOYhS7W7z/iWCc2ow3vrZ cJT9cOSIG46yFlzpUbMI2ULHda4VC1vkOLQ8U= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=7ka4URs0CTGU3VgKnph52Sd8bIRvP/WyTfE635VTfRQ=; b=W7NISqPgTjMnGyuuU+6WPXCVnD5SJoXaOnXCqctbwmnqonDB8sYEjW+BIKMhjgUwBa 5TrBlREK6SCYxcriZxSnmVhpFoSdT3of+oyZsMT5zd73NB0xEDfzCzksmDAAJH/X+e57 0HKlv7LSuNAEC+L+MqYHW+IdjCJap0MtVg4DXksMrvS7Vx90QlhPZBFG3D1dUWyh03ZJ kLClwIHrGNHz6KlL1O6taJe1ssIliZZZsTtDUukbKMhc6WVCHpjGA5+mmtuPnr4skyQB kx9Oy4zKbwp1oIqaQEU0VHcTLK2N9YHM6bPsFNpv4GNpRqJKVSjh2Cc5VwUpVT6dMzuG KyzA== X-Gm-Message-State: AEkooutGcHN7e/LMyU+SiV3G4JyArLJczDZ3mAYco2dm0SAY4PGu5rZzQyOOPC+gqNNREABX X-Received: by 10.194.75.37 with SMTP id z5mr23079662wjv.102.1471942373779; Tue, 23 Aug 2016 01:52:53 -0700 (PDT) Received: from [10.11.211.24] ([192.19.213.250]) by smtp.gmail.com with ESMTPSA id m81sm26240066wmf.1.2016.08.23.01.52.51 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 23 Aug 2016 01:52:53 -0700 (PDT) To: Kalle Valo , =?UTF-8?Q?Toke_H=c3=b8iland-J=c3=b8rg?= =?UTF-8?Q?ensen?= References: <20160706193417.13080-1-toke@toke.dk> <20160805160346.10545-1-toke@toke.dk> <87mvk44xmt.fsf@purkki.adurom.net> <87bn0k4w4d.fsf@toke.dk> <87fupwvisn.fsf@kamboji.qca.qualcomm.com> <871t1g4thz.fsf@toke.dk> <877fb8ug0x.fsf@kamboji.qca.qualcomm.com> Cc: linux-wireless@vger.kernel.org, make-wifi-fast@lists.bufferbloat.net, ath9k-devel@lists.ath9k.org, Tim Shepard , Felix Fietkau From: Arend van Spriel Message-ID: <57157bcd-498d-537c-875f-1ff8c7f82b80@broadcom.com> User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <877fb8ug0x.fsf@kamboji.qca.qualcomm.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Mailman-Approved-At: Mon, 28 Nov 2016 08:47:10 -0500 Subject: Re: [Make-wifi-fast] [PATCH v4] ath9k: Switch to using mac80211 intermediate software queues. X-BeenThere: make-wifi-fast@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Date: Tue, 23 Aug 2016 08:52:55 -0000 X-Original-Date: Tue, 23 Aug 2016 10:52:48 +0200 X-List-Received-Date: Tue, 23 Aug 2016 08:52:55 -0000 On 23-08-16 08:59, Kalle Valo wrote: > Toke Høiland-Jørgensen writes: > >>>>> This is great work but due to the regressions I'm not sure if this >>>>> will be ready for 4.9. To get more testing time I wonder if we should >>>>> wait for 4.10? IMHO applying this in the end of the cycle is too risky >>>>> and we should try to maximise the time linux-next by applying this >>>>> just after -rc1 is released. >>>>> >>>>> Thoughts? >>>> >>>> Well, now that we understand what is causing the throughput regressions, >>>> fixing them should be fairly straight forward (yeah, famous last words, >>>> but still...). I already have a patch for the fast path and will go poke >>>> at the slow path next. It'll probably require another workaround or two, >>>> so I guess it won't be the architecturally clean ideal solution; but it >>>> would make it possible to have something that works for 4.9 and then >>>> iterate for a cleaner design for 4.10. >>> >>> But if we try to rush this to 4.9 it won't be in linux-next for long. We >>> are now in -rc3 and let's say that the patches are ready to apply in two >>> weeks. That would leave us only two weeks of -next time before the merge >>> window, which I think is not enough for a controversial patch like this >>> one. There might be other bugs lurking which haven't been found yet. >> >> What, other hidden bugs? Unpossible! :) > > Yeah, right ;) > >> Would it be possible to merge the partial solution (which is ready now, >> basically) and fix the slow path in a separate patch later? > > What do you mean with partial solution? You mean ath9k users would > suffer from regressions until they are fixed? We can't do that. > >> (Just spit-balling here; I'm still fairly new to this process. But I am >> concerned that we'll hit a catch-22 where we can't get wider testing >> before it's "ready" and we can't prove that it's "ready" until we've had >> wider testing...) So could the wider testing be accomplished by working on a branch in the wireless-testing repo and make its availability known on wireless-list, ath?k-list, LWN or whatever. Regards, Arend > I understand your point, but I don't want to rush this to 4.9 and then > start getting lots of bug reports and eventually forced to revert it. If > we just found a new serious regression the chances are that there are > more lurking somewhere and this patch is just not ready yet.