Re: NimBLE host - flat bufs vs. mbufs

Hello all, I have gone ahead and updated the host API on develop to use mbufs rather than flat bufs. This was a fairly big update, so you might want to hold off on pulling from develop until it is a good time to deal with API changes. I think the new API is an improvement over the old one, but

Re: NimBLE host - flat bufs vs. mbufs

+ 1 for mbufs. Greater potential for zero-copy stack, ease of sizing for different memory footprint etc. And you can always move data to contiguous area, when parsing in-place is inconvenient. > On Jul 19, 2016, at 9:15 AM, Sterling Hughes wrote: > > +1 for Mbufs vs flat

Re: NimBLE host - flat bufs vs. mbufs

On Tue, Jul 19, 2016 at 03:56:46PM +0200, Kevin Townsend wrote: > I'm curious what you would have done for a simple FIFO where you are > likely storing 1 or 2 bytes at a time? If there isn't a good match, > perhaps it's worth adding a very light weight FIFO or circular buffer > that can deal

Re: NimBLE host - flat bufs vs. mbufs

On Tue, Jul 19, 2016 at 06:38:02AM -0700, will sanfilippo wrote: > I am +1 for mbufs. While they do take a bit of getting used to, I > think converting the host to use them is the way to go, especially if > they replace a large flat buffer pool. > > I also think we should mention that mbufs use a

Re: NimBLE host - flat bufs vs. mbufs

We were actually discussing some buffer problems internally this weekend, debating mbuf versus other solutions, etc. We needed a simple FIFO to store data from Nordic's BLE UART service until the end user wants to access it, and we recycled some existing FIFO code we implemented for Nordic's