Hello all, This email concerns the type of data buffers that the NimBLE host requires the application to use. There are several instances in which buffers are passed between host and application. For example, when the application performs a GATT write procedure, it supplies the data to be written by passing a buffer to the host.
The core of Mynewt presents two different mechanisms for implementing data buffers: 1. Flat bufs 2. Mbufs A flat buf is a pointer to a region of contiguous storage and is usually accompanied by a length argument. This is what the POSIX socket API uses in its send() and recv() functions, for example. Mbufs are dynamically resizable buffer chains. They are described in much more detail here: http://mynewt.apache.org/latest/os/core_os/mbuf/mbuf/ The NimBLE host uses flat bufs, which makes it a bit of an outlier. Among all the core network libraries, the host appears to be the only one whose API is not based on mbufs. In particular, I am comparing the NimBLE host to mn_socket and newtmgr. While it may be a bit painful to switch, I have convinced myself that it ultimately makes more sense for the host to use mbufs instead of flat bufs. I put together two lists: reasons to prefer flat bufs and reasons to prefer mbufs. Pro flat buf: * Simple interface. Pro mbuf: * Consistent with the rest of Mynewt core. * More memory efficient (no need to pre-allocate a large ATT buffer; share memory with the rest of the system). * More speed efficient (NimBLE host already uses mbufs internally; no need to convert between the two buffer types). I ordered the items in the "pro mbuf" list from most to least important, as I see it. As much as I appreciate the simplicity of flat bufs, I have to place a greater importance on consistency of the system as a whole. I have had a difficult time deciding on this issue, and I would be very interested in hearing any and all thoughts on the subject. Absent overwhelming disapproval, I am going to get started on implementing this change on a separate branch. That way we will have something more concrete to evaluate. Thanks, Chris
