You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@mynewt.apache.org by GitBox <gi...@apache.org> on 2019/07/03 11:34:51 UTC

[GitHub] [mynewt-nimble] andrzej-kaczmarek edited a comment on issue #477: npl/riot: reduce default MSYS_1_BLOCK_SIZE to minimum

andrzej-kaczmarek edited a comment on issue #477: npl/riot: reduce default MSYS_1_BLOCK_SIZE to minimum
URL: https://github.com/apache/mynewt-nimble/pull/477#issuecomment-507873873
 
 
   Proper minimum value for `MSYS_1_BLOCK_SIZE` is 80, assuming you do not use extended advertising. This allows to store `CONNECT_IND` PDU in a single mbuf, i.e. without creating a chain.
   
   To store complete `CONNECT_IND` PDU we need 76 bytes:
   - 16 bytes for `os_mbuf` header
   - 8 bytes for `os_mbuf_pkthdr`
   - 16 bytes for `ble_mbuf_hdr`
   - 36 bytes for LL PDU with `CONNECT_IND` payload (2 + 34)
   
   However, to move packets from RX ISR to LL task we use `ble_ll_rxpdu_alloc` which adds 4 bytes at the beginning of 1st mbuf for extra header used when moving ACL data to HCI transport. This gives 80 bytes in total. The reason why 77 works for you is because block size is aligned to word size, so it's 80 anyway.
   
   Note that even with lower value we can pass PDUs from RX ISR to LL task properly by using mbuf chains, however there are few places in code which assume that complete PDU is available in first mbuf as this simply makes code faster (you can read data from flat array) and this is exactly the case when parsing `CONNECT_IND` - with chain in mbuf we'll just read some random data for certain parameters and connection won't work.
   
   As for minimum number of blocks, I do not know what is the absolute minimum required but anyway I do not recommend to set this to such value since it can simply make things fail randomly. For example, you do not really know when received ACL data will be processed and freed by host (assuming RAM transport is used for HCI) and while they are queued either in controller or in host you may not be able to receive new packets. Of course we'll NAK incoming packets so eventually they will be received (unless supervision timeout hits) but performance won't be great. I do not also know what is a reasonably good low value though.

----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
users@infra.apache.org


With regards,
Apache Git Services