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;
MIME-Version: 1.0
References: <CAO1O6sdGJeAKTHBVyDSUa7-Hp_ULYmfOHJEbb6=-B6xuPHvffQ@mail.gmail.com>
 <CABBYNZKtxPmTUn2fw9-dy1V9M_Pb996O6VmHkg4NrAr-=t+-4A@mail.gmail.com>
 <CAO1O6sdke-2J=eYHS2SoG83v-hMJDBu-gasufJYDyHK+1R+w5g@mail.gmail.com>
 <CH2PR14MB3658759A2701FB52A2D6573BE6E50@CH2PR14MB3658.namprd14.prod.outlook.com>
 <CAO1O6sfwcEswTkuuntoBM_S5oFkQv7mCP1GH8Z0S0vgHk2Bp5A@mail.gmail.com>
 <CABBYNZ+2v5Z05dSD+TrzioGYVWugZJGpBnq+2M=MO-smuVgXbA@mail.gmail.com>
 <CAO1O6sfWgqnduM8_UuO_1W8KjnEvoetbk6bcaA_ATFUaXLtB0w@mail.gmail.com>
 <CABBYNZJrWBVEY7ZUxqFShfPne2b=6ahDOd3srJF6NAJwQLWQpQ@mail.gmail.com> <CAO1O6sfp2ikCkAY3UGvxe-+F-L-nG=cdTqjzthrv4ddrADxWnw@mail.gmail.com>
In-Reply-To: <CAO1O6sfp2ikCkAY3UGvxe-+F-L-nG=cdTqjzthrv4ddrADxWnw@mail.gmail.com>
From:   Luiz Augusto von Dentz <luiz.dentz@gmail.com>
Date:   Wed, 4 Mar 2020 15:02:12 -0800
Message-ID: <CABBYNZ+K+bPSaQLP=+etjhu=xPOszV6MApzyMe0-YhrTL0e-Jg@mail.gmail.com>
Subject: Re: Get negotiated ATT MTU?
To:     Emil Lenngren <emil.lenngren@gmail.com>
Cc:     Jamie Mccrae <Jamie.Mccrae@lairdconnect.com>,
        Bluez mailing list <linux-bluetooth@vger.kernel.org>
Content-Type: text/plain; charset="UTF-8"
Sender: linux-bluetooth-owner@vger.kernel.org
Precedence: bulk

Hi Emil,

On Wed, Mar 4, 2020 at 2:41 PM Emil Lenngren <emil.lenngren@gmail.com> wrote:
>
> Hi Luiz,
>
> Den ons 4 mars 2020 kl 20:44 skrev Luiz Augusto von Dentz
> <luiz.dentz@gmail.com>:
> > > > It completely transparent to D-Bus, so if we do expose the MTU it
> > > > should probably be reporting the biggest MTU of all connected channel,
> > >
> > > Is there ever any reason for one application to have more than one ATT
> > > bearer? I thought the idea of EATT was to allow one ATT bearer per
> > > application.
> >
> > EATT is meant to allow multiple outstanding requests, it probably
> > would not escale if we would add an API to have a bearer per
> > application so we just use the extra bearers as a pool.
>
> I just read the 5.2 overview and 5.2 specification again and I see now
> that the overview suggests that a pool of bearers should be used, as
> you mentioned. So yes in that case the maximum ATT_MTU of the bearers
> seems reasonable to report (if they for some reason would differ). But
> by having a pool like this, I hope implementations will make sure that
> multiple Write Without Response values or notifications from the same
> application are sent on a single bearer, to avoid reorderings.

Commands don't need a response so in theory one should just use the
unenhanced bearer or the first one EATT bearer regardless, in the
current implementation I just pick the first bearer that allow sending
all the data in one shot given that the MTU can be different.

-- 
Luiz Augusto von Dentz