Re: [I] GAP callback when receiving HCI completed packets [mynewt-nimble]

["xyzzy42 (via GitHub)" <gi...@apache.org>]

xyzzy42 commented on issue #1170:
URL: https://github.com/apache/mynewt-nimble/issues/1170#issuecomment-1872500793

   I'm trying to implement high bandwidth streaming from the BLE server to the client, using Notify, which is something I've done before with another BLE stack.
   
   Discovered the same thing @Rubeer found.  `BLE_GAP_EVENT_NOTIFY_TX` is pretty much useless, since it only indicates the packet has been queued, not when it's transmitted.  Since it's called directly from `ble_gattc_notify_custom()`, it's hard to imagine a use case where the code in the callback that handles the event couldn't just has easily been called from wherever `ble_gattc_notify_custom()` was called from.
   
   From @sjanc's response, I wonder if the NimBLE devs were aware it operates this way?
   
   I'm not after low latency, but high bandwidth.  To achieve high bandwidth it's necessary to queue multiple packets per connection interval.  If one just queues as many notifies (or anything) as possible, all memory on the controller is exhausted and it can't respond to incoming packets.  And one gets a huge buffer of packets that adds lots of latency.
   
   The way I solved this with Nordic's stack was to limit the number of outstanding buffered packets to some number.  It needs to be at least the number to sent on one connection interval.   This can be done by just keeping track of the number of notifies queued when they are added, and then decrementing the count when they are transmitted.  But one needs a callback when TX occurs, which NimBLE appears to lack.
    
   I'm coming to the same conclusion as @tannewt, that I need to insert some sort of callback into `ble_hs_hci_evt_num_completed_pkts()`.
   
   The problem is that nothing in NimBLE keeps track of what packets were sent to the controller.  So there's no way to dispatch a callback that identifies the specific Notify which has been completed when the HCI event reports completed packets.
   
   The packet count alone in a callback isn't enough for an application to do flow control. An ATT packet can be fragmented into multiple LL packets by L2CAP.  And NimBLE will send responses to various requests, which queues packets the application doesn't know about.
   
   So if the app queues four Notify ops, and gets four completed packets in a callback, that could mean:  All four notifies have completed; one notify was split into four fragments and completed and three notifies are still outstanding; there were four responses to connection parameter requests transmitted and all four notifies are still fully queued.


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: commits-unsubscribe@mynewt.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org