Received: by 2002:a25:8b91:0:0:0:0:0 with SMTP id j17csp1359857ybl; Wed, 29 Jan 2020 21:20:20 -0800 (PST) X-Google-Smtp-Source: APXvYqydKtChIBGmtxBYxWCJ8AEuOTe7hdTM2xv8pzD32h9WICK9e3Sp/Y8sMrNyOzeZNUdgf98x X-Received: by 2002:a9d:51c1:: with SMTP id d1mr2152966oth.136.1580361620377; Wed, 29 Jan 2020 21:20:20 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1580361620; cv=none; d=google.com; s=arc-20160816; b=TRfXiNLNHCiTlBvZ8VEFt7s1s6dfxWlFPagr+9D2Il6WgYKVdMAgWKFam60ch29b9R ki3IDr3ZaIQXfHpcGeYtyr7aSMaXLabP9eW54kTmgEvlB5QlsGZ1LybFRj3H86q6+iSr SmyafCrsmHfQgguIpmRVdkxtnYbENJ3KzRWdUFswgKBAUhx81XEN1eHtxweqv/ea9Mi+ AATA+wp5OmwZfno+UHoBcvoRJs77w9575U8QiZSDwEdwDHrTLHTj4qxfcfK1/iiCUxrW 0Wy4u/zIh/IxC6ZuN/tQtkC6FEVteqpkung1vJGErAOjit9/UiISBXbFwqfxlYdW5dLS fQ2w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=vCPHJREq4iRGuiNz9Pn0NktTpek3dx8mHhpUo4kMVmk=; b=CBTPyVFiyI3YGP2rIRk2R7Zb7CqEY2hhGKb1FqO455m5DV5ovAroXEst2GzUVWJPlv qd3FqZ6mnmz8ls/9Hr+6ccZN43g52LngEIC/WpF+WmGOohjFQZWdCHNp1MhKuyh1Bdun y5HfC5f4s4uAJa2YvLjpOcySmoKtMHbIlNLQZTDD/i0JNW7TSeIeSp75wP2E8/YuuCGz T4oirFVOEvYtD+1dKL2W/VX7/6F9imoX7pbLUD/Q/fSILReEglyMk6fdGP5+OgZdf2Vm G6BMVoZjmCs5r+cBt+n6lpHL0uiZWvkVE5w2eH5DRDOPKMuybeXRIr5ujP1XNEpZi38V fwEQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=KMf0fe8v; spf=pass (google.com: best guess record for domain of linux-bluetooth-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-bluetooth-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id m25si2460936otn.208.2020.01.29.21.19.50; Wed, 29 Jan 2020 21:20:20 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-bluetooth-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=KMf0fe8v; spf=pass (google.com: best guess record for domain of linux-bluetooth-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-bluetooth-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1725847AbgA3FTp (ORCPT + 99 others); Thu, 30 Jan 2020 00:19:45 -0500 Received: from mail-il1-f196.google.com ([209.85.166.196]:43563 "EHLO mail-il1-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725798AbgA3FTo (ORCPT ); Thu, 30 Jan 2020 00:19:44 -0500 Received: by mail-il1-f196.google.com with SMTP id o13so1991509ilg.10 for ; Wed, 29 Jan 2020 21:19:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=vCPHJREq4iRGuiNz9Pn0NktTpek3dx8mHhpUo4kMVmk=; b=KMf0fe8v5mPOrgIZFMpumqnHK1hDiNLm7EeMLChuB4NnWkMZ0Inge41LgFBgHbD0Xi G8IlZZ38BVAOmW/awdy097sTmjGIIknI+upJLIMvNMIHcIU4VYevuY+oT6m3HZFSMUFX d26zWXqscokCD48NmMlknJ9LMtCf5SO3oY12u/HQUmxsQnoKXlNHvfzDGf0ymrwuyc5S Bm6ouFl5ECNOfcM2uZbmHfNhGUvAI8KY/1aKQZO86zTib+lxBU53C+gv31aVFtZTy92+ 0npDghJZ+Ne7VNa3X9yK2GaNuSxlN/cOIZioUiJu5yWK+ryZtwdrR6HWhIsJ8QkrklrN Zkqg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=vCPHJREq4iRGuiNz9Pn0NktTpek3dx8mHhpUo4kMVmk=; b=cT75Kb9tSAABPxjJjsJZcH7B8MErVTNAiwzNK3zijhU3skxT0RU72Sd2kf7k07x89V 3S6WdQPBB/DyHQULM5J5kkpZUVddaG8BATdDG2sjnPiVGqkN8orFqVEidHzYunpqd8zH D1LxDeAG3+FF1rzMCQNxtKpISPY+4qOeG4LdSLTR3nxqjA4JSxbfQoTWjqfNAEpo13wO UAoxDA/1dE2nLixYEl07XtUghHn3NqtsKaRVDt/21ucHuTMJgiReJcV0PuOAxLKZCEyQ PH+l8xSl8nzKJpEZhLzZo/j48iXCYeem03BuRHfrGZvJ6XrNIqJshVGSeZXl2ZbFN8MD 1bAw== X-Gm-Message-State: APjAAAWNnJzbkl/p5+C9fPH9cJVqy6Z/W1N8usLlE829UvBk/PicKT1a n9dXK8mmxzSGe93MNzDYSZExV6FMAhKbJfhbMDc= X-Received: by 2002:a05:6e02:c0c:: with SMTP id d12mr2684667ile.185.1580361583756; Wed, 29 Jan 2020 21:19:43 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Sathish Narasimman Date: Thu, 30 Jan 2020 10:49:32 +0530 Message-ID: Subject: Re: L2CAP mtu preference set by user space clarification To: Luiz Augusto von Dentz Cc: chethan tn , Bluez mailing list , Chethan T N , Sathish Narasimman , Sathish N Content-Type: text/plain; charset="UTF-8" Sender: linux-bluetooth-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-bluetooth@vger.kernel.org Hi Luiz, Requesting your feedback/suggestion to the below case. On Tue, Jan 28, 2020 at 12:31 PM Sathish Narasimman 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 > wrote: > > > > Hi Chethan, > > > > On Mon, Dec 16, 2019 at 10:40 PM chethan tn 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