I am talking about GATT reads, where the mbuf is pre-allocated for the app
to fill in:
- static int
- gatt_svr_chr_access_gap(
- uint16_t conn_handle,
- uint16_t attr_handle,
- struct ble_gatt_access_ctxt *ctxt, void *arg)
- {
- ...
- os_mbuf_append(ctxt->om, data, len);
- ...
- }
-
- Similarly, GATT read ops triggered by ble_gatt_chr_updated for sending
out notifications.
-
On 20 Jan. 2017 1:48 pm, "Christopher Collins" <[email protected]> wrote:
> On Fri, Jan 20, 2017 at 01:21:20PM -0800, Simon Ratner wrote:
> > On Fri, Jan 20, 2017 at 9:01 AM, Christopher Collins <
> [email protected]>
> > wrote:
> > > On Thu, Jan 19, 2017 at 11:57:01PM -0800, Simon Ratner wrote:
> > > > When allocating mbufs for the payload, is there something I should
> do to
> > > > reserve enough leading space for the ACL header to make sure host
> doesn't
> > > > need to re-allocate it?
> > >
> > > Yes - you should use ble_hs_mbuf_att_pkt() to allocate all your mbufs.
> > > This function ensures the resulting mbuf has sufficient leading space
> > > for:
> > > * ACL data header
> > > * Basic L2CAP header
> > > * Four bytes for an ATT command
> > >
> >
> > And I assume the mbuf passed into gatt read handlers (ctxt->om) has been
> > allocated that way? I only need to worry about the mbufs I allocate
> myself,
> > such as for notify payload.
>
> The mbufs handed up from the host are typically allocated by something
> else (e.g., for the combined host-controller, it is the controller which
> allocates them). If you pass these mbufs back to the host, there is a
> chance the host will need to allocate an additional buffer while
> prepending to the chain. The host stripped the headers from the front
> of the mbuf before handing it to the application, so there will be
> sufficient leading space to add them back. However, the problem is the
> variable length ATT command. Your outgoing command may require more
> "ATT bytes" than the one you received.
>
> Do you often pass these mbufs back to the host? I thought that would be
> an uncommon use case.
>
> Chris
>
