You are viewing a plain text version of this content. The canonical link for it is here.
Posted to notifications@mynewt.apache.org by "Christopher Collins (JIRA)" <ji...@apache.org> on 2017/01/22 18:29:27 UTC

[jira] [Resolved] (MYNEWT-555) BLE Host - Avoid mbuf copy on chr read

     [ https://issues.apache.org/jira/browse/MYNEWT-555?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Christopher Collins resolved MYNEWT-555.
----------------------------------------
    Resolution: Fixed

> BLE Host - Avoid mbuf copy on chr read
> --------------------------------------
>
>                 Key: MYNEWT-555
>                 URL: https://issues.apache.org/jira/browse/MYNEWT-555
>             Project: Mynewt
>          Issue Type: Bug
>          Components: Nimble
>            Reporter: Christopher Collins
>            Assignee: Christopher Collins
>             Fix For: v1_0_0_rel
>
>
> When the host receives any form of characteristic read request, an extraneous mbuf gets allocated.  The sequence is:
> * Allocate new mbuf.
> * Pass new mbuf to application code so app can fill in characteristic value.
> * Copy characteristic value out of new mbuf into response mbuf
> * Free new mbuf
> The reason for the extra allocation is to simplify reads that specify non-zero offsets. In the case of a GATT read, the peer may read from different offsets of the characteristic. In an effort to simplify the API, I decided the requested offset should be hidden from the application.  Instead, the application always provides the full characteristic value, and the host copies the requested portion out of the user-filled mbuf and into the ACL data packet.
> The fix is to try to reuse the response to hold the characteristic data.  This can be done if the read request specifies an offset of 0.  For non-zero offsets, the old behavior remains: allocate an extra mbuf and copy the data.
> Additional context: https://lists.apache.org/thread.html/78358745716cac9512b3c659dfe9b9b7bbb1354ee4c38d6da137bcc0@%3Cdev.mynewt.apache.org%3E



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)