Hi , This is regarding the patch submitted in bluetooth-next.git regarding LE Data Length Extension feature. This feature basically allows for a greater packet size to be used and thus increase throughput while transmitting data. My question is do we have any advantage of using a smaller data packet size? If not why cant we just set the variable "connInitialMaxTxOctets" to 255 in the controller ? This way we wont need any new HCI commands/events. Setting the default value to 255 also won't cause any problems in dealing with legacy hosts. Here is a more detailed explanation: If we set the variable "connInitialMaxTxOctets" to 255 then the variable "connMaxTxOctets" which is specific to a particular connection would be set to 255 whenever a new connection is established. However the default value of "connRemoteMaxOctets" is 27(as per spec). Therefore the value of "connEffectiveMaxTxOctets" would be 27 only as it is the minimum of "connMaxTxOctets" and "connRemoteMaxOctets" . Therefore setting "connInitialMaxTxOctets" to 255 would not cause problems with a legacy host. If the other host is a v4.2 device then the variable "connRemoteMaxTxOctets" would be set to 255 as a Data Length Update procedure would be initiated as soon as a new connection is established [as per specification ]. Therefore we don't face any problem if the device is legacy or not. However my question is do we have any advantage of setting the packet length to a smaller value ? If not, then we can simply set the default value of "connInitialMaxTxOctets" to 255 and do without any HCI commands/events. Regards, Abhinav Kumar ------- Original Message ------- Sender : Abhinav Kumar<abhinav.ku91@xxxxxxxxxxx> Senior Software Engineer/SRI-Bangalore-SWC/Samsung Electronics Date : Mar 06, 2015 19:33 (GMT+09:00) Title : Re: Re: [PATCH ] [BT][LE Data Length Extension] Hi , This is regarding the patch submitted in bluetooth-next.git regarding LE Data Length Extension feature. This feature basically allows for a greater packet size to be used and thus increase throughput while transmitting data. My question is do we have any advantage of using a smaller data packet size? If not why cant we just set the variable "connInitialMaxTxOctets" to 255 in the controller ? This way we wont need any new HCI commands/events. Setting the default value to 255 also won't cause any problems in dealing with legacy hosts. Here is a more detailed explanation: If we set the variable "connInitialMaxTxOctets" to 255 then the variable "connMaxTxOctets" which is specific to a particular connection would be set to 255 whenever a new connection is established. However the default value of "connRemoteMaxOctets" is 27(as per spec). Therefore the value of "connEffectiveMaxTxOctets" would be 27 only as it is the minimum of "connMaxTxOctets" and "connRemoteMaxOctets" . Therefore setting "connInitialMaxTxOctets" to 255 would not cause problems with a legacy host. If the other host is a v4.2 device then the variable "connRemoteMaxTxOctets" would be set to 255 as a Data Length Update procedure would be initiated as soon as a new connection is established [as per specification ]. Therefore we don't face any problem if the device is legacy or not. However my question is do we have any advantage of setting the packet length to a smaller value ? If not, then we can simply set the default value of "connInitialMaxTxOctets" to 255 and do without any HCI commands/events. Regards, Abhinav Kumar ------- Original Message ------- Sender : Johan Hedberg<johan.hedberg@xxxxxxxxx> Date : Mar 04, 2015 18:05 (GMT+09:00) Title : Re: [PATCH ] [BT][LE Data Length Extension] Hi Abhinav, On Wed, Mar 04, 2015, Abhinav Kumar wrote: > 1> Added kernel code for for all commands and events which are part of the feature. > > Signed-off-by: Abhinav Kumar > --- > include/net/bluetooth/hci_core.h | 13 ++- > include/net/bluetooth/mgmt.h | 40 +++++++++ > net/bluetooth/hci_conn.c | 27 ++++++ > net/bluetooth/hci_event.c | 35 +++++++- > net/bluetooth/mgmt.c | 169 ++++++++++++++++++++++++++++++++++++++ > 5 files changed, 280 insertions(+), 4 deletions(-) A couple of things: 1) The very first thing that needs to happen is for a user space mgmt-api.txt patch to be submitted and get applied before we do any changes. This will require some good justifications for why you need this exposed to user space, and why it needs to happen pretty much 1:1 to the respective HCI commands. 2) You need to split the kernel changes into multiple smaller patches. You can e.g. introduce the HCI definitions in one patch and the implementation in another. Same goes for mgmt definitions and implementation. 3) Fix your coding style. There are probably multiple things but one obvious one I saw was with variable naming: we don't use CamelCase anywhere in the kernel (or BlueZ user space for that matter). 4) Use hci_request if you need to have a function in mgmt.c called after a HCI command completion, instead of having a hard-coded call from hci_event.c into mgmt.c. 5) For all of your patches you need to provide more extensive commit messages. It's good to have a short summary of what the patch does, but for most patches it's even more important to explain why the patch is needed and why the approach it takes is the best one. Johan -- To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.htmlÿôèº{.nÇ+‰·Ÿ®‰†+%ŠËÿ±éݶ;¥Šwÿº{.nÇ+‰·¥Š{±ý¹nzÚ(¶ âžØ^n‡r¡ö¦zË?ëh™¨èÚ&£ûàz¿äz¹Þ—ú+€Ê+zf£¢·hšˆ§~††Ûiÿÿï?êÿ‘êçz_è®æj:+v‰¨þ)ߣøm
