Re: MBUF sizing for the bluetooth stack

2017-01-22 Thread Christopher Collins
On Sun, Jan 22, 2017 at 09:16:59AM -0800, Christopher Collins wrote: > There are some optimizations that could be done here. In most cases, > the host is interested in the full attribute value. The host should > probably allocate GATT read mbufs using ble_hs_mbuf_att_pkt() in these > cases so

Re: MBUF sizing for the bluetooth stack

2017-01-22 Thread Christopher Collins
On Fri, Jan 20, 2017 at 02:27:41PM -0800, Simon Ratner wrote: > 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,

Re: MBUF sizing for the bluetooth stack

2017-01-20 Thread Simon Ratner
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); - ... - } - -

Re: MBUF sizing for the bluetooth stack

2017-01-20 Thread Christopher Collins
On Fri, Jan 20, 2017 at 01:21:20PM -0800, Simon Ratner wrote: > On Fri, Jan 20, 2017 at 9:01 AM, Christopher Collins > 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 > > >

Re: MBUF sizing for the bluetooth stack

2017-01-20 Thread Simon Ratner
On Fri, Jan 20, 2017 at 9:01 AM, Christopher Collins wrote: > On Thu, Jan 19, 2017 at 11:57:01PM -0800, Simon Ratner wrote: > > Thanks Chris, > > > > It appears to me that there is questionable benefit to having mbufs sized > > larger than the largest L2CAP fragment size

Re: MBUF sizing for the bluetooth stack

2017-01-20 Thread Christopher Collins
On Thu, Jan 19, 2017 at 11:57:01PM -0800, Simon Ratner wrote: > Thanks Chris, > > It appears to me that there is questionable benefit to having mbufs sized > larger than the largest L2CAP fragment size (plus overhead), i.e. the 80 > bytes that Will mentioned. Is that a reasonable statement, or am

Re: MBUF sizing for the bluetooth stack

2017-01-20 Thread will sanfilippo
Simon: I think you are pretty much correct; generally you are better off with smaller size mbufs. However, there are cases where larger mbufs are better (for example, a very large portion of your data packets are large). > On Jan 19, 2017, at 11:57 PM, Simon Ratner wrote: > >

Re: MBUF sizing for the bluetooth stack

2017-01-19 Thread Simon Ratner
Thanks Chris, It appears to me that there is questionable benefit to having mbufs sized larger than the largest L2CAP fragment size (plus overhead), i.e. the 80 bytes that Will mentioned. Is that a reasonable statement, or am I missing something? For incoming data, you always waste memory with

Re: MBUF sizing for the bluetooth stack

2017-01-19 Thread Christopher Collins
On Thu, Jan 19, 2017 at 10:57:58AM -0800, Christopher Collins wrote: > On Thu, Jan 19, 2017 at 03:46:49AM -0800, Simon Ratner wrote: > > A related question: how does this map to large ATT_MTU and fragmented > > packets at the L2CAP level (assuming no data length extension)? Does each > > fragment

Re: MBUF sizing for the bluetooth stack

2017-01-19 Thread Christopher Collins
On Thu, Jan 19, 2017 at 03:46:49AM -0800, Simon Ratner wrote: > A related question: how does this map to large ATT_MTU and fragmented > packets at the L2CAP level (assuming no data length extension)? Does each > fragment get its own mbuf, which are then chained together, or does the > entire

Re: MBUF sizing for the bluetooth stack

2017-01-19 Thread will sanfilippo
That is a good question. I should let Chris answer this one as he knows for sure. I suspect you will have a chain of mbufs but I would have to look over the code to be sure. > On Jan 19, 2017, at 3:46 AM, Simon Ratner wrote: > > Hi Will, > > A related question: how does this

Re: MBUF sizing for the bluetooth stack

2017-01-19 Thread Simon Ratner
Hi Will, A related question: how does this map to large ATT_MTU and fragmented packets at the L2CAP level (assuming no data length extension)? Does each fragment get its own mbuf, which are then chained together, or does the entire packet get reassembled into a single mbuf if there is room? On

Re: MBUF sizing for the bluetooth stack

2017-01-11 Thread will sanfilippo
Yes; 76 or 80. Note that I have not actually tested with 80 byte mbuf blocks. That is the theory though :-) > On Jan 11, 2017, at 4:31 PM, Simon Ratner wrote: > > Got it; by minimum size you mean the 76/80 bytes? > > On Wed, Jan 11, 2017 at 4:17 PM, will sanfilippo

Re: MBUF sizing for the bluetooth stack

2017-01-11 Thread Simon Ratner
Got it; by minimum size you mean the 76/80 bytes? On Wed, Jan 11, 2017 at 4:17 PM, will sanfilippo wrote: > Well, yes, there are “definitions” for these things. They are in various > places but they are there. Using them might get a bit tricky as you have > mentioned; not

Re: MBUF sizing for the bluetooth stack

2017-01-11 Thread will sanfilippo
Well, yes, there are “definitions” for these things. They are in various places but they are there. Using them might get a bit tricky as you have mentioned; not sure. You would have to make sure the right header files get included in the proper places... Anyway, here are the definitions: os

Re: MBUF sizing for the bluetooth stack

2017-01-11 Thread Simon Ratner
Thanks for the detailed write-up, Will - very useful. Are there defines for these things? Ideally, if I want a payload size of N, I'd like to specify in syscfg.yml: MSYS_1_BLOCK_SIZE: '(N + MBUF_HEADER + PKT_HEADER + LL_OVERHEAD + ...)' And magically have optimally-sized buffers. On Wed,