[
https://issues.apache.org/jira/browse/MYNEWT-287?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15798679#comment-15798679
]
Christopher Collins commented on MYNEWT-287:
--------------------------------------------
Thanks, Johan, that is very interesting to hear. Will and I were just
discussing this issue yesterday: flow control for ACL data, but no means of
stopping the controller from sending events. After giving it some thought, I
agree that relying on the underlying transport's flow control mechanism should
be sufficient (better actually, because it controls the flow of both data and
events). I wonder why controller-to-host flow control is even specified in
bluetooth. Do you have any insight into the rationale? Maybe this flow
control was specified in case a new HCI transport which does not have its own
flow control mechanism gets added to the spec.
> Host Flow Control
> -----------------
>
> Key: MYNEWT-287
> URL: https://issues.apache.org/jira/browse/MYNEWT-287
> Project: Mynewt
> Issue Type: New Feature
> Components: Nimble
> Environment: Using nimble from an external host stack
> Reporter: Johan Hedberg
> Assignee: Christopher Collins
> Fix For: v1_0_0_rel
>
>
> If the Nimble controller part is connected to an external host stack the host
> may need to control the flow of ACL packets from the controller to the host.
> This is particularly important for resource-constrained hosts that have a
> limited amount of RX ACL data buffers.
> The Bluetooth core specification provides a standard feature to accomplish
> this called Host Flow Control. (Vol 2, Part E, Section 4.2). To implement
> this the controller needs to support the "Set Controller To Host Flow
> Control", "Host Buffer Size" and "Host Number Of Completed Packets" HCI
> commands.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
