Return-Path: From: Jonah Petri Message-Id: <4F61E0A6-999F-441F-9062-8E01DC79205B@sense.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_CEDD1662-8606-45DB-A6F1-6F9CC38AD9EF" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: [PATCH] gatt-server: Implement NegotiatedMTU property on Device1 Date: Mon, 17 Jul 2017 11:30:41 -0400 In-Reply-To: <8E72D5C7-FA44-4B06-82D7-2FCB22E26778@holtmann.org> Cc: Luiz Augusto von Dentz , "linux-bluetooth@vger.kernel.org" To: Marcel Holtmann References: <8E72D5C7-FA44-4B06-82D7-2FCB22E26778@holtmann.org> List-ID: --Apple-Mail=_CEDD1662-8606-45DB-A6F1-6F9CC38AD9EF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hello Marcel and Luiz, Thanks for looking at the patch! > On Jul 15, 2017, at 2:03 PM, Marcel Holtmann = wrote: >=20 >>> --- a/doc/device-api.txt >>> +++ b/doc/device-api.txt >>> @@ -234,3 +234,8 @@ Properties string Address [readonly] >>> array{byte} AdvertisingFlags [readonly, experimental] >>>=20 >>> The Advertising Data Flags of the remote = device. >>> + >>> + int16 NegotiatedMTU [readonly, optional, = experimental] >>> + >>> + The ATT MTU negotiated with the connected = host. >>> + Available only once MTU negotiation is = complete. >>=20 >> Despite being odd that we start exposing transport specific details = on >> device interface, there maybe a chance this is useful if we can >> properly detect BR/EDR MTU not only LE, though this means checking = the >> via bt_att API not bt_gatt_server. Obviously, this would have to be >> exposed even before it is negotiated since LE start with 23 but on >> BR/EDR this is negotiated via L2CAP signaling, and perhaps it should >> not really be MTU that we expose but the actual payload without the >> headers that bluetoothd takes care of adding. >=20 > I think that exposing max payload is a better idea. I am fine with the revised naming, and revising the exposed device = attribute to represent the max ATT payload. However, how can a dbus = client know whether the MTU negotiation has occurred or not? The point = of the patch is to allow for clients to take advantage of a larger = negotiated MTU. The negotiation of the MTU can be a significant event to the client = interacting via dbus, so how should the completion of that negotiation = be exposed, if not via an attribute as I proposed above? Some boolean = "MaxPayloadNegotiationCompleted" method? Jonah= --Apple-Mail=_CEDD1662-8606-45DB-A6F1-6F9CC38AD9EF Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hello Marcel and Luiz,

Thanks for looking at the patch!

On Jul 15, 2017, at 2:03 PM, Marcel Holtmann <marcel@holtmann.org>= wrote:

--- a/doc/device-api.txt
+++ = b/doc/device-api.txt
@@ -234,3 +234,8 @@ Properties =  string Address [readonly]
          &nb= sp;   array{byte} AdvertisingFlags [readonly, = experimental]

          &nb= sp;           The = Advertising Data Flags of the remote device.
+
+ =             &n= bsp; int16 NegotiatedMTU [readonly, optional, experimental]
+
+ =             &n= bsp;         The ATT MTU = negotiated with the connected host.
+ =             &n= bsp;         Available only = once MTU negotiation is complete.

Despite being odd that we start exposing transport specific = details on
device interface, there maybe a chance this is = useful if we can
properly detect BR/EDR MTU not only LE, = though this means checking the
via bt_att API not = bt_gatt_server. Obviously, this would have to be
exposed = even before it is negotiated since LE start with 23 but on
BR/EDR this is negotiated via L2CAP signaling, and perhaps it = should
not really be MTU that we expose but the actual = payload without the
headers that bluetoothd takes care of = adding.

I think that = exposing max payload is a better idea.

I= am fine with the revised naming, and revising the exposed device = attribute to represent the max ATT payload.  However, how can a = dbus client know whether the MTU negotiation has occurred or not? =  The point of the patch is to allow for clients to take advantage = of a larger negotiated MTU.

The negotiation of the MTU can be a significant event to the = client interacting via dbus, so how should the completion of that = negotiation be exposed, if not via an attribute as I proposed above? =  Some boolean "MaxPayloadNegotiationCompleted" method?

Jonah
= --Apple-Mail=_CEDD1662-8606-45DB-A6F1-6F9CC38AD9EF--