Return-Path: Subject: Re: [PATCH 0/3] RFC: prioritizing data over HCI From: Marcel Holtmann To: Mat Martineau Cc: Gustavo Padovan , Peter Hurley , Luiz Augusto von Dentz , linux-bluetooth@vger.kernel.org, pkrystad@codeaurora.org Date: Wed, 10 Aug 2011 17:18:18 -0700 In-Reply-To: References: <1312377094-11285-1-git-send-email-luiz.dentz@gmail.com> <1312499377.2158.36.camel@THOR> <20110805191210.GA2537@joana> <20110809043210.GA2594@joana> Content-Type: text/plain; charset="UTF-8" Message-ID: <1313021902.3373.130.camel@aeonflux> Mime-Version: 1.0 Sender: linux-bluetooth-owner@vger.kernel.org List-ID: Hi Mat, > > So in the next step for ERTM we move the queue to L2CAP and create a callback > > to call from HCI at the moment of push data to the baseband. The function in > > L2CAP would set the last control bits in the first packet of the queue and > > sent it through. > > This actually causes some problems for ERTM, since skbs are cloned > before they are pushed to HCI. skb data is not supposed to be > modified after cloning. > > If there's a callback to L2CAP anyway, why not have L2CAP provide the > skb at that time instead of modifying data it provided earlier? > > > > Then the queue can be split in two by adding a pointer that will mark which > > element divides the queue between prio and normal. New prio skbs would just be > > queued after this element and before the rest. > > I think it's simpler and less bug-prone to just have two queues. > Either way, it's one more pointer. > > However, I'm still not sure we want any queues in hci_chan. It's not > very complicated to have the queue in the L2CAP layer, and gives ERTM > the control it needs. I am fine if we just queue in L2CAP actually. Since nobody should send ACL packets directly (besides the crazy people that wanna abuse BlueZ's support for HCI_RAW for 3rd party stacks) anyway. In a real fully integrated stack only L2CAP will send ACL data packets and we can just rely on that fact if want to. Regards Marcel