Re: [PATCH 0/3] RFC: prioritizing data over HCI

[Marcel Holtmann <marcel@holtmann.org>]

Hi Mat,

<snip>

> > 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