* L2CAP mtu preference set by user space clarification @ 2019-12-17 6:36 chethan tn 2019-12-18 0:19 ` Luiz Augusto von Dentz 0 siblings, 1 reply; 6+ messages in thread From: chethan tn @ 2019-12-17 6:36 UTC (permalink / raw) To: Bluez mailing list, chethan ಚೇತನ್, Chethan T N, nsathish41, sathish.narasimman Hi, I would like to understand why the Source device L2CAP mtu is always set to the remote device mtu during L2CAP connection? https://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth.git/tree/net/bluetooth/l2cap_core.c#n3370 https://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth.git/tree/net/bluetooth/l2cap_core.c#n3474 I tried to set the specific MTU for specific profile connection( For Ex: A2DP connection - PSM 25) patch mentioned below, but the same is not reflected because of the below code. https://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth.git/tree/net/bluetooth/l2cap_core.c#n3474 Here the patch to set the MTU from the use space bluez. diff --git a/profiles/audio/a2dp.c b/profiles/audio/a2dp.c index 58e1534a4..7d8a718c0 100644 --- a/profiles/audio/a2dp.c +++ b/profiles/audio/a2dp.c @@ -1573,6 +1573,7 @@ static bool a2dp_server_listen(struct a2dp_server *server) BT_IO_OPT_SOURCE_BDADDR, btd_adapter_get_address(server->adapter), BT_IO_OPT_PSM, AVDTP_PSM, + BT_IO_OPT_OMTU, AVDTP_MTU, BT_IO_OPT_SEC_LEVEL, BT_IO_SEC_MEDIUM, BT_IO_OPT_MASTER, true, BT_IO_OPT_INVALID); diff --git a/profiles/audio/avdtp.c b/profiles/audio/avdtp.c index 51ead684a..786702cec 100644 --- a/profiles/audio/avdtp.c +++ b/profiles/audio/avdtp.c @@ -2394,6 +2394,7 @@ static GIOChannel *l2cap_connect(struct avdtp *session) BT_IO_OPT_DEST_BDADDR, device_get_address(session->device), BT_IO_OPT_PSM, AVDTP_PSM, + BT_IO_OPT_OMTU, AVDTP_MTU, BT_IO_OPT_SEC_LEVEL, BT_IO_SEC_MEDIUM, BT_IO_OPT_INVALID); if (!io) { diff --git a/profiles/audio/avdtp.h b/profiles/audio/avdtp.h index 621a6e3cf..372b2579d 100644 --- a/profiles/audio/avdtp.h +++ b/profiles/audio/avdtp.h Can you please suggest what is the best way to set the L2CAP mtu as user defined. Thanks Chethan ^ permalink raw reply related [flat|nested] 6+ messages in thread
* Re: L2CAP mtu preference set by user space clarification 2019-12-17 6:36 L2CAP mtu preference set by user space clarification chethan tn @ 2019-12-18 0:19 ` Luiz Augusto von Dentz 2020-01-28 7:01 ` Sathish Narasimman 0 siblings, 1 reply; 6+ messages in thread From: Luiz Augusto von Dentz @ 2019-12-18 0:19 UTC (permalink / raw) To: chethan tn; +Cc: Bluez mailing list, Chethan T N, Sathish N, Sathish Narasimman Hi Chethan, On Mon, Dec 16, 2019 at 10:40 PM chethan tn <chethantn@gmail.com> wrote: > > Hi, > > I would like to understand why the Source device L2CAP mtu is always > set to the remote device mtu during L2CAP connection? > > https://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth.git/tree/net/bluetooth/l2cap_core.c#n3370 > https://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth.git/tree/net/bluetooth/l2cap_core.c#n3474 > > > > I tried to set the specific MTU for specific profile connection( For > Ex: A2DP connection - PSM 25) patch mentioned below, but the same is > not reflected because of the below code. > > https://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth.git/tree/net/bluetooth/l2cap_core.c#n3474 The answer is pretty simple, we don't control the remote/output MTU, so we cannot force the remote to use some arbitrary MTU if it doesn't agree with. > Here the patch to set the MTU from the use space bluez. > > diff --git a/profiles/audio/a2dp.c b/profiles/audio/a2dp.c > index 58e1534a4..7d8a718c0 100644 > --- a/profiles/audio/a2dp.c > +++ b/profiles/audio/a2dp.c > @@ -1573,6 +1573,7 @@ static bool a2dp_server_listen(struct a2dp_server *server) > BT_IO_OPT_SOURCE_BDADDR, > btd_adapter_get_address(server->adapter), > BT_IO_OPT_PSM, AVDTP_PSM, > + BT_IO_OPT_OMTU, AVDTP_MTU, > BT_IO_OPT_SEC_LEVEL, BT_IO_SEC_MEDIUM, > BT_IO_OPT_MASTER, true, > BT_IO_OPT_INVALID); > diff --git a/profiles/audio/avdtp.c b/profiles/audio/avdtp.c > index 51ead684a..786702cec 100644 > --- a/profiles/audio/avdtp.c > +++ b/profiles/audio/avdtp.c > @@ -2394,6 +2394,7 @@ static GIOChannel *l2cap_connect(struct avdtp *session) > BT_IO_OPT_DEST_BDADDR, > device_get_address(session->device), > BT_IO_OPT_PSM, AVDTP_PSM, > + BT_IO_OPT_OMTU, AVDTP_MTU, > BT_IO_OPT_SEC_LEVEL, BT_IO_SEC_MEDIUM, > BT_IO_OPT_INVALID); > if (!io) { > diff --git a/profiles/audio/avdtp.h b/profiles/audio/avdtp.h > index 621a6e3cf..372b2579d 100644 > --- a/profiles/audio/avdtp.h > +++ b/profiles/audio/avdtp.h > > > > Can you please suggest what is the best way to set the L2CAP mtu as > user defined. > > > Thanks > > Chethan -- Luiz Augusto von Dentz ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: L2CAP mtu preference set by user space clarification 2019-12-18 0:19 ` Luiz Augusto von Dentz @ 2020-01-28 7:01 ` Sathish Narasimman 2020-01-30 5:19 ` Sathish Narasimman 2020-01-30 19:12 ` Luiz Augusto von Dentz 0 siblings, 2 replies; 6+ messages in thread From: Sathish Narasimman @ 2020-01-28 7:01 UTC (permalink / raw) To: Luiz Augusto von Dentz Cc: chethan tn, Bluez mailing list, Chethan T N, Sathish Narasimman, Sathish N Hi Luiz, There are some headsets that configure the MTU to 850(3M PHY) and then under some situation(noisy), it switches to 2M PHY packets for A2DP playback. The reason behind this is their receiver's capability for better demodulation with QDPSK(2M PHY) when compared to 8DPSK(3M PHY). From Bluetooth specification, the remote device can request the LMP_preferred_rate with the LMP command to switch to 2M. When Baseband PHY is 2M, the maximum possible packet type is 2DH5 which can hold 679 bytes ( 672 bytes of L2CAP MTU excluding the baseband headers). When L2CAP MTU for an A2DP packet is larger than 672 bytes, it happens to use 2 Baseband packets to deliver the L2CAP packet ie., like 1 2DH5(679 bytes) and 1 2DH3(171 bytes) packet to deliver 850 bytes of AVDTP Media. The is not efficient baseband utilization when the number of baseband ACL buffers used 2 no.s or even less that may lead to the delivery of one L2CAP packet that may take 4 slots more ( 2.5 ms more). When the remote device ( headset) has less number of baseband ACL buffers and Host(source) is aggressively delivering the audio data to render, it shall end up in a condition where the remote device does Flow OFF that shall make the Source device to wait until next FLOW ON send from the headset device. This kind of situation shall end up accumulating more buffers and FLOW ON/OFF become cyclic and leads to an audio break. Is there a better solution to overcome this issue? We considered changing the HOST MTU to 672bytes to overcome this issue that makes the remote headset device to use 2M. And found that the test results are positive. On Wed, Dec 18, 2019 at 5:49 AM Luiz Augusto von Dentz <luiz.dentz@gmail.com> wrote: > > Hi Chethan, > > On Mon, Dec 16, 2019 at 10:40 PM chethan tn <chethantn@gmail.com> wrote: > > > > Hi, > > > > I would like to understand why the Source device L2CAP mtu is always > > set to the remote device mtu during L2CAP connection? > > > > https://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth.git/tree/net/bluetooth/l2cap_core.c#n3370 > > https://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth.git/tree/net/bluetooth/l2cap_core.c#n3474 > > > > > > > > I tried to set the specific MTU for specific profile connection( For > > Ex: A2DP connection - PSM 25) patch mentioned below, but the same is > > not reflected because of the below code. > > > > https://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth.git/tree/net/bluetooth/l2cap_core.c#n3474 > > The answer is pretty simple, we don't control the remote/output MTU, > so we cannot force the remote to use some arbitrary MTU if it doesn't > agree with. > > > Here the patch to set the MTU from the use space bluez. > > > > diff --git a/profiles/audio/a2dp.c b/profiles/audio/a2dp.c > > index 58e1534a4..7d8a718c0 100644 > > --- a/profiles/audio/a2dp.c > > +++ b/profiles/audio/a2dp.c > > @@ -1573,6 +1573,7 @@ static bool a2dp_server_listen(struct a2dp_server *server) > > BT_IO_OPT_SOURCE_BDADDR, > > btd_adapter_get_address(server->adapter), > > BT_IO_OPT_PSM, AVDTP_PSM, > > + BT_IO_OPT_OMTU, AVDTP_MTU, > > BT_IO_OPT_SEC_LEVEL, BT_IO_SEC_MEDIUM, > > BT_IO_OPT_MASTER, true, > > BT_IO_OPT_INVALID); > > diff --git a/profiles/audio/avdtp.c b/profiles/audio/avdtp.c > > index 51ead684a..786702cec 100644 > > --- a/profiles/audio/avdtp.c > > +++ b/profiles/audio/avdtp.c > > @@ -2394,6 +2394,7 @@ static GIOChannel *l2cap_connect(struct avdtp *session) > > BT_IO_OPT_DEST_BDADDR, > > device_get_address(session->device), > > BT_IO_OPT_PSM, AVDTP_PSM, > > + BT_IO_OPT_OMTU, AVDTP_MTU, > > BT_IO_OPT_SEC_LEVEL, BT_IO_SEC_MEDIUM, > > BT_IO_OPT_INVALID); > > if (!io) { > > diff --git a/profiles/audio/avdtp.h b/profiles/audio/avdtp.h > > index 621a6e3cf..372b2579d 100644 > > --- a/profiles/audio/avdtp.h > > +++ b/profiles/audio/avdtp.h > > > > > > > > Can you please suggest what is the best way to set the L2CAP mtu as > > user defined. > > > > > > Thanks > > > > Chethan > > > > -- > Luiz Augusto von Dentz Regards Sathish N ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: L2CAP mtu preference set by user space clarification 2020-01-28 7:01 ` Sathish Narasimman @ 2020-01-30 5:19 ` Sathish Narasimman 2020-01-30 19:12 ` Luiz Augusto von Dentz 1 sibling, 0 replies; 6+ messages in thread From: Sathish Narasimman @ 2020-01-30 5:19 UTC (permalink / raw) To: Luiz Augusto von Dentz Cc: chethan tn, Bluez mailing list, Chethan T N, Sathish Narasimman, Sathish N Hi Luiz, Requesting your feedback/suggestion to the below case. On Tue, Jan 28, 2020 at 12:31 PM Sathish Narasimman <nsathish41@gmail.com> wrote: > > Hi Luiz, > > There are some headsets that configure the MTU to 850(3M PHY) and then > under some situation(noisy), it switches to 2M PHY packets for A2DP > playback. The reason behind this is their receiver's capability for > better demodulation with QDPSK(2M PHY) when compared to 8DPSK(3M PHY). > > From Bluetooth specification, the remote device can request the > LMP_preferred_rate with the LMP command to switch to 2M. When Baseband > PHY is 2M, the maximum possible packet type is 2DH5 which can hold > 679 bytes ( 672 bytes of L2CAP MTU excluding the baseband headers). > > When L2CAP MTU for an A2DP packet is larger than 672 bytes, it happens > to use 2 Baseband packets to deliver the L2CAP packet ie., like 1 > 2DH5(679 bytes) and 1 2DH3(171 bytes) packet to deliver 850 bytes of > AVDTP Media. The is not efficient baseband utilization when the number > of baseband ACL buffers used 2 no.s or even less that may lead to the > delivery of one L2CAP packet that may take 4 slots more ( 2.5 ms > more). > > When the remote device ( headset) has less number of baseband ACL > buffers and Host(source) is aggressively delivering the audio data to > render, it shall end up in a condition where the remote device does > Flow OFF that shall make the Source device to wait until next FLOW ON > send from the headset device. This kind of situation shall end up > accumulating more buffers and FLOW ON/OFF become cyclic and leads to > an audio break. > > Is there a better solution to overcome this issue? > > We considered changing the HOST MTU to 672bytes to overcome this issue > that makes the remote headset device to use 2M. And found that the > test results are positive. > > > On Wed, Dec 18, 2019 at 5:49 AM Luiz Augusto von Dentz > <luiz.dentz@gmail.com> wrote: > > > > Hi Chethan, > > > > On Mon, Dec 16, 2019 at 10:40 PM chethan tn <chethantn@gmail.com> wrote: > > > > > > Hi, > > > > > > I would like to understand why the Source device L2CAP mtu is always > > > set to the remote device mtu during L2CAP connection? > > > > > > https://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth.git/tree/net/bluetooth/l2cap_core.c#n3370 > > > https://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth.git/tree/net/bluetooth/l2cap_core.c#n3474 > > > > > > > > > > > > I tried to set the specific MTU for specific profile connection( For > > > Ex: A2DP connection - PSM 25) patch mentioned below, but the same is > > > not reflected because of the below code. > > > > > > https://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth.git/tree/net/bluetooth/l2cap_core.c#n3474 > > > > The answer is pretty simple, we don't control the remote/output MTU, > > so we cannot force the remote to use some arbitrary MTU if it doesn't > > agree with. > > > > > Here the patch to set the MTU from the use space bluez. > > > > > > diff --git a/profiles/audio/a2dp.c b/profiles/audio/a2dp.c > > > index 58e1534a4..7d8a718c0 100644 > > > --- a/profiles/audio/a2dp.c > > > +++ b/profiles/audio/a2dp.c > > > @@ -1573,6 +1573,7 @@ static bool a2dp_server_listen(struct a2dp_server *server) > > > BT_IO_OPT_SOURCE_BDADDR, > > > btd_adapter_get_address(server->adapter), > > > BT_IO_OPT_PSM, AVDTP_PSM, > > > + BT_IO_OPT_OMTU, AVDTP_MTU, > > > BT_IO_OPT_SEC_LEVEL, BT_IO_SEC_MEDIUM, > > > BT_IO_OPT_MASTER, true, > > > BT_IO_OPT_INVALID); > > > diff --git a/profiles/audio/avdtp.c b/profiles/audio/avdtp.c > > > index 51ead684a..786702cec 100644 > > > --- a/profiles/audio/avdtp.c > > > +++ b/profiles/audio/avdtp.c > > > @@ -2394,6 +2394,7 @@ static GIOChannel *l2cap_connect(struct avdtp *session) > > > BT_IO_OPT_DEST_BDADDR, > > > device_get_address(session->device), > > > BT_IO_OPT_PSM, AVDTP_PSM, > > > + BT_IO_OPT_OMTU, AVDTP_MTU, > > > BT_IO_OPT_SEC_LEVEL, BT_IO_SEC_MEDIUM, > > > BT_IO_OPT_INVALID); > > > if (!io) { > > > diff --git a/profiles/audio/avdtp.h b/profiles/audio/avdtp.h > > > index 621a6e3cf..372b2579d 100644 > > > --- a/profiles/audio/avdtp.h > > > +++ b/profiles/audio/avdtp.h > > > > > > > > > > > > Can you please suggest what is the best way to set the L2CAP mtu as > > > user defined. > > > > > > > > > Thanks > > > > > > Chethan > > > > > > > > -- > > Luiz Augusto von Dentz > > Regards > Sathish N ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: L2CAP mtu preference set by user space clarification 2020-01-28 7:01 ` Sathish Narasimman 2020-01-30 5:19 ` Sathish Narasimman @ 2020-01-30 19:12 ` Luiz Augusto von Dentz 2020-01-31 5:07 ` Sathish Narasimman 1 sibling, 1 reply; 6+ messages in thread From: Luiz Augusto von Dentz @ 2020-01-30 19:12 UTC (permalink / raw) To: Sathish Narasimman Cc: chethan tn, Bluez mailing list, Chethan T N, Sathish Narasimman Hi Sathish, On Mon, Jan 27, 2020 at 11:02 PM Sathish Narasimman <nsathish41@gmail.com> wrote: > > Hi Luiz, > > There are some headsets that configure the MTU to 850(3M PHY) and then > under some situation(noisy), it switches to 2M PHY packets for A2DP > playback. The reason behind this is their receiver's capability for > better demodulation with QDPSK(2M PHY) when compared to 8DPSK(3M PHY). > > From Bluetooth specification, the remote device can request the > LMP_preferred_rate with the LMP command to switch to 2M. When Baseband > PHY is 2M, the maximum possible packet type is 2DH5 which can hold > 679 bytes ( 672 bytes of L2CAP MTU excluding the baseband headers). > > When L2CAP MTU for an A2DP packet is larger than 672 bytes, it happens > to use 2 Baseband packets to deliver the L2CAP packet ie., like 1 > 2DH5(679 bytes) and 1 2DH3(171 bytes) packet to deliver 850 bytes of > AVDTP Media. The is not efficient baseband utilization when the number > of baseband ACL buffers used 2 no.s or even less that may lead to the > delivery of one L2CAP packet that may take 4 slots more ( 2.5 ms > more). > > When the remote device ( headset) has less number of baseband ACL > buffers and Host(source) is aggressively delivering the audio data to > render, it shall end up in a condition where the remote device does > Flow OFF that shall make the Source device to wait until next FLOW ON > send from the headset device. This kind of situation shall end up > accumulating more buffers and FLOW ON/OFF become cyclic and leads to > an audio break. > > Is there a better solution to overcome this issue? > > We considered changing the HOST MTU to 672bytes to overcome this issue > that makes the remote headset device to use 2M. And found that the > test results are positive. But we only control the RX/input MTU not the TX/output MTU, so the headset is at fault here it should have reconfigured the MTU accordingly. For the RX/input there is a patch already adjusting the MTU automatically when the socket MTU is set to 0: commit 4b6e228e297b73451f3a4b12fb7d0b24d9d32e6f Author: Luiz Augusto von Dentz <luiz.von.dentz@intel.com> Date: Thu Jan 2 15:00:57 2020 -0800 Bluetooth: Auto tune if input MTU is set to 0 This enables the code to set the input MTU using the underline link packet types when set to 0, previously this would likely be rejected by the remote peer since it would be bellow the minimal of 48 for BR/EDR or 23 for LE, that way it shall be safe to use 0 without causing any side effects. This is convenient for the likes of A2DP transport, see: https://habr.com/en/post/456182/ Without the remote side updating the MTU the host has no idea of the changes to the packet type, also we would have to notify the upper layer of the change if that happens mid stream, this relation between packet type is not very clear to the L2CAP layer since it doesn't distinct what data the upper layer is sending so we cannot just do the MTU change locally and limit the output MTU based on the underline link, expect perhaps if we would be willing to do that when MTU is set to 0 in which we would artificially limit the packet length based on the supported packet types, but does the controller notifies this sort of change to the host at all? > > On Wed, Dec 18, 2019 at 5:49 AM Luiz Augusto von Dentz > <luiz.dentz@gmail.com> wrote: > > > > Hi Chethan, > > > > On Mon, Dec 16, 2019 at 10:40 PM chethan tn <chethantn@gmail.com> wrote: > > > > > > Hi, > > > > > > I would like to understand why the Source device L2CAP mtu is always > > > set to the remote device mtu during L2CAP connection? > > > > > > https://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth.git/tree/net/bluetooth/l2cap_core.c#n3370 > > > https://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth.git/tree/net/bluetooth/l2cap_core.c#n3474 > > > > > > > > > > > > I tried to set the specific MTU for specific profile connection( For > > > Ex: A2DP connection - PSM 25) patch mentioned below, but the same is > > > not reflected because of the below code. > > > > > > https://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth.git/tree/net/bluetooth/l2cap_core.c#n3474 > > > > The answer is pretty simple, we don't control the remote/output MTU, > > so we cannot force the remote to use some arbitrary MTU if it doesn't > > agree with. > > > > > Here the patch to set the MTU from the use space bluez. > > > > > > diff --git a/profiles/audio/a2dp.c b/profiles/audio/a2dp.c > > > index 58e1534a4..7d8a718c0 100644 > > > --- a/profiles/audio/a2dp.c > > > +++ b/profiles/audio/a2dp.c > > > @@ -1573,6 +1573,7 @@ static bool a2dp_server_listen(struct a2dp_server *server) > > > BT_IO_OPT_SOURCE_BDADDR, > > > btd_adapter_get_address(server->adapter), > > > BT_IO_OPT_PSM, AVDTP_PSM, > > > + BT_IO_OPT_OMTU, AVDTP_MTU, > > > BT_IO_OPT_SEC_LEVEL, BT_IO_SEC_MEDIUM, > > > BT_IO_OPT_MASTER, true, > > > BT_IO_OPT_INVALID); > > > diff --git a/profiles/audio/avdtp.c b/profiles/audio/avdtp.c > > > index 51ead684a..786702cec 100644 > > > --- a/profiles/audio/avdtp.c > > > +++ b/profiles/audio/avdtp.c > > > @@ -2394,6 +2394,7 @@ static GIOChannel *l2cap_connect(struct avdtp *session) > > > BT_IO_OPT_DEST_BDADDR, > > > device_get_address(session->device), > > > BT_IO_OPT_PSM, AVDTP_PSM, > > > + BT_IO_OPT_OMTU, AVDTP_MTU, > > > BT_IO_OPT_SEC_LEVEL, BT_IO_SEC_MEDIUM, > > > BT_IO_OPT_INVALID); > > > if (!io) { > > > diff --git a/profiles/audio/avdtp.h b/profiles/audio/avdtp.h > > > index 621a6e3cf..372b2579d 100644 > > > --- a/profiles/audio/avdtp.h > > > +++ b/profiles/audio/avdtp.h > > > > > > > > > > > > Can you please suggest what is the best way to set the L2CAP mtu as > > > user defined. > > > > > > > > > Thanks > > > > > > Chethan > > > > > > > > -- > > Luiz Augusto von Dentz > > Regards > Sathish N -- Luiz Augusto von Dentz ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: L2CAP mtu preference set by user space clarification 2020-01-30 19:12 ` Luiz Augusto von Dentz @ 2020-01-31 5:07 ` Sathish Narasimman 0 siblings, 0 replies; 6+ messages in thread From: Sathish Narasimman @ 2020-01-31 5:07 UTC (permalink / raw) To: Luiz Augusto von Dentz Cc: chethan tn, Bluez mailing list, Chethan T N, Sathish Narasimman Hi Luiz Thanks for the suggestion. On Fri, Jan 31, 2020 at 12:42 AM Luiz Augusto von Dentz <luiz.dentz@gmail.com> wrote: > > Hi Sathish, > > On Mon, Jan 27, 2020 at 11:02 PM Sathish Narasimman > <nsathish41@gmail.com> wrote: > > > > Hi Luiz, > > > > There are some headsets that configure the MTU to 850(3M PHY) and then > > under some situation(noisy), it switches to 2M PHY packets for A2DP > > playback. The reason behind this is their receiver's capability for > > better demodulation with QDPSK(2M PHY) when compared to 8DPSK(3M PHY). > > > > From Bluetooth specification, the remote device can request the > > LMP_preferred_rate with the LMP command to switch to 2M. When Baseband > > PHY is 2M, the maximum possible packet type is 2DH5 which can hold > > 679 bytes ( 672 bytes of L2CAP MTU excluding the baseband headers). > > > > When L2CAP MTU for an A2DP packet is larger than 672 bytes, it happens > > to use 2 Baseband packets to deliver the L2CAP packet ie., like 1 > > 2DH5(679 bytes) and 1 2DH3(171 bytes) packet to deliver 850 bytes of > > AVDTP Media. The is not efficient baseband utilization when the number > > of baseband ACL buffers used 2 no.s or even less that may lead to the > > delivery of one L2CAP packet that may take 4 slots more ( 2.5 ms > > more). > > > > When the remote device ( headset) has less number of baseband ACL > > buffers and Host(source) is aggressively delivering the audio data to > > render, it shall end up in a condition where the remote device does > > Flow OFF that shall make the Source device to wait until next FLOW ON > > send from the headset device. This kind of situation shall end up > > accumulating more buffers and FLOW ON/OFF become cyclic and leads to > > an audio break. > > > > Is there a better solution to overcome this issue? > > > > We considered changing the HOST MTU to 672bytes to overcome this issue > > that makes the remote headset device to use 2M. And found that the > > test results are positive. > > But we only control the RX/input MTU not the TX/output MTU, so the > headset is at fault here it should have reconfigured the MTU > accordingly. For the RX/input there is a patch already adjusting the > MTU automatically when the socket MTU is set to 0: > > commit 4b6e228e297b73451f3a4b12fb7d0b24d9d32e6f > Author: Luiz Augusto von Dentz <luiz.von.dentz@intel.com> > Date: Thu Jan 2 15:00:57 2020 -0800 > > Bluetooth: Auto tune if input MTU is set to 0 > > This enables the code to set the input MTU using the underline link > packet types when set to 0, previously this would likely be rejected by > the remote peer since it would be bellow the minimal of 48 for BR/EDR > or 23 for LE, that way it shall be safe to use 0 without causing any > side effects. > > This is convenient for the likes of A2DP transport, see: > > https://habr.com/en/post/456182/ > > Without the remote side updating the MTU the host has no idea of the > changes to the packet type, also we would have to notify the upper > layer of the change if that happens mid stream, this relation between > packet type is not very clear to the L2CAP layer since it doesn't > distinct what data the upper layer is sending so we cannot just do the > MTU change locally and limit the output MTU based on the underline > link, expect perhaps if we would be willing to do that when MTU is set > to 0 in which we would artificially limit the packet length based on > the supported packet types, but does the controller notifies this sort > of change to the host at all? > > > > > On Wed, Dec 18, 2019 at 5:49 AM Luiz Augusto von Dentz > > <luiz.dentz@gmail.com> wrote: > > > > > > Hi Chethan, > > > > > > On Mon, Dec 16, 2019 at 10:40 PM chethan tn <chethantn@gmail.com> wrote: > > > > > > > > Hi, > > > > > > > > I would like to understand why the Source device L2CAP mtu is always > > > > set to the remote device mtu during L2CAP connection? > > > > > > > > https://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth.git/tree/net/bluetooth/l2cap_core.c#n3370 > > > > https://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth.git/tree/net/bluetooth/l2cap_core.c#n3474 > > > > > > > > > > > > > > > > I tried to set the specific MTU for specific profile connection( For > > > > Ex: A2DP connection - PSM 25) patch mentioned below, but the same is > > > > not reflected because of the below code. > > > > > > > > https://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth.git/tree/net/bluetooth/l2cap_core.c#n3474 > > > > > > The answer is pretty simple, we don't control the remote/output MTU, > > > so we cannot force the remote to use some arbitrary MTU if it doesn't > > > agree with. > > > > > > > Here the patch to set the MTU from the use space bluez. > > > > > > > > diff --git a/profiles/audio/a2dp.c b/profiles/audio/a2dp.c > > > > index 58e1534a4..7d8a718c0 100644 > > > > --- a/profiles/audio/a2dp.c > > > > +++ b/profiles/audio/a2dp.c > > > > @@ -1573,6 +1573,7 @@ static bool a2dp_server_listen(struct a2dp_server *server) > > > > BT_IO_OPT_SOURCE_BDADDR, > > > > btd_adapter_get_address(server->adapter), > > > > BT_IO_OPT_PSM, AVDTP_PSM, > > > > + BT_IO_OPT_OMTU, AVDTP_MTU, > > > > BT_IO_OPT_SEC_LEVEL, BT_IO_SEC_MEDIUM, > > > > BT_IO_OPT_MASTER, true, > > > > BT_IO_OPT_INVALID); > > > > diff --git a/profiles/audio/avdtp.c b/profiles/audio/avdtp.c > > > > index 51ead684a..786702cec 100644 > > > > --- a/profiles/audio/avdtp.c > > > > +++ b/profiles/audio/avdtp.c > > > > @@ -2394,6 +2394,7 @@ static GIOChannel *l2cap_connect(struct avdtp *session) > > > > BT_IO_OPT_DEST_BDADDR, > > > > device_get_address(session->device), > > > > BT_IO_OPT_PSM, AVDTP_PSM, > > > > + BT_IO_OPT_OMTU, AVDTP_MTU, > > > > BT_IO_OPT_SEC_LEVEL, BT_IO_SEC_MEDIUM, > > > > BT_IO_OPT_INVALID); > > > > if (!io) { > > > > diff --git a/profiles/audio/avdtp.h b/profiles/audio/avdtp.h > > > > index 621a6e3cf..372b2579d 100644 > > > > --- a/profiles/audio/avdtp.h > > > > +++ b/profiles/audio/avdtp.h > > > > > > > > > > > > > > > > Can you please suggest what is the best way to set the L2CAP mtu as > > > > user defined. > > > > > > > > > > > > Thanks > > > > > > > > Chethan > > > > > > > > > > > > -- > > > Luiz Augusto von Dentz > > > > Regards > > Sathish N > > > > -- > Luiz Augusto von Dentz ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2020-01-31 5:07 UTC | newest] Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2019-12-17 6:36 L2CAP mtu preference set by user space clarification chethan tn 2019-12-18 0:19 ` Luiz Augusto von Dentz 2020-01-28 7:01 ` Sathish Narasimman 2020-01-30 5:19 ` Sathish Narasimman 2020-01-30 19:12 ` Luiz Augusto von Dentz 2020-01-31 5:07 ` Sathish Narasimman
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).