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
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,
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);
- ...
- }
-
-
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
> > >
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
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
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:
>
>
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
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
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
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
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
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
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
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
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,
16 matches
Mail list logo