Re: [PATCH] Bluetooth: Process HCI events in a workqueue instead of a tasklet

[Marcel Holtmann <marcel@holtmann.org>]

Hi David,

> >>>> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
> >>>> ---
> >>>>  include/net/bluetooth/hci_core.h |    2 +
> >>>>  net/bluetooth/hci_core.c         |   58 ++++++++++++++++++++++++++++++++-----
> >>>>  2 files changed, 52 insertions(+), 8 deletions(-)
> >>> so I stuffed this now into bluetooth-testing tree and would like to see
> >>> some extra testing exposure. So far this has only been tested by myself.
> >>>
> >>> If there are no regression then this should make a lot of HCI and L2CAP
> >>> handling a lot simple.
> >> This may result in packets being processed in a different order to that 
> >> which they were received in.
> >>
> >> e.g., what happens to an ACL packet processed before the connection 
> >> complete event for that connection?
> > 
> > good point. So we would either a) need to disable the RX tasklet when we
> > receive an event and schedule it for processing or b) process the ACL
> > data also in a workqueue.
> 
> I think my preferred solution would be for the rx function called by the 
> HCI transport drivers to be called in a thread context.  There should be 
> a helper function that is callable in atomic context that queues the 
> packets to be processed in a workqueue.
> 
> Our UWB drivers already process packets in a thread so would prefer to 
> avoid another thread context switch.
> 
> Shall I prepare a patch?

yes please. I need something to make the event handling simpler.
Otherwise every single subcomponent creates "hundreds" of workqueues to
solve exactly the same problem.

Regards

Marcel