Return-path: Received: from mail-wi0-f182.google.com ([209.85.212.182]:41061 "EHLO mail-wi0-f182.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751923Ab3BYFII (ORCPT ); Mon, 25 Feb 2013 00:08:08 -0500 Received: by mail-wi0-f182.google.com with SMTP id hi18so2710607wib.3 for ; Sun, 24 Feb 2013 21:08:07 -0800 (PST) MIME-Version: 1.0 In-Reply-To: <1361726886.8129.9.camel@jlt4.sipsolutions.net> References: <1361564916.3420.11.camel@jlt4.sipsolutions.net> <1361726886.8129.9.camel@jlt4.sipsolutions.net> Date: Sun, 24 Feb 2013 21:08:07 -0800 Message-ID: (sfid-20130225_060814_162283_B5F04602) Subject: Re: [PATCH 1/2] [RFC] cfg80211: configuration of Bluetooth coexistence mode From: Adrian Chadd To: Johannes Berg Cc: Arend Van Spriel , "linux-wireless@vger.kernel.org" , Piotr Haber Content-Type: text/plain; charset=ISO-8859-1 Sender: linux-wireless-owner@vger.kernel.org List-ID: On 24 February 2013 09:28, Johannes Berg wrote: >> In the driver we could inspect each sk_buff and boost priority of any >> BOOTP packets so that it will end up in the AC_VO fifo and have >> hardware coexistence handle it further. I consider that more a >> pragmatic fix, which is not always the worst thing to go for. > > Well, I don't really think that's the best idea. Sniffing the protocol > is clumsy at best. Sure, but it's the kind of thing that commercial devices do in order to work around real world issues. So it'd be nice to have a programmatic way to detect things (eg bootp packets going out) and signal the driver via some side channel to do things like btcoex weight changing. But it'd also be nice to do it based on QoS too. >> However, I would prefer a solution is which user-space, ie. dhcp >> client can control the priority and/or BT coexistence. > > It's not just BT coex btw, with multi-channel support it might also be > interesting to not switch channels while DHCP is going on, for example. Right. Adrian