All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Michał Lowas-Rzechonek" <michal.lowas-rzechonek@silvair.com>
To: "linux-bluetooth@vger.kernel.org" <linux-bluetooth@vger.kernel.org>
Subject: Re: Plans for meshd
Date: Tue, 18 Dec 2018 12:08:38 +0100	[thread overview]
Message-ID: <20181218110838.ollsqils5ci7cq4v@scytale> (raw)
In-Reply-To: <DEBB0CAA2616974FAE35E4B560B9A4375D8E02FE@ORSMSX101.amr.corp.intel.com>

Hi Brian,

Thanks for clarifying.

On Mon, Dec 17, 2018 at 09:48:34PM +0000, Gix, Brian wrote:
> I consider this to be a practical approach, because the overhead
> consumed by ACL connections negatively affects Advertising based
> communications, and linux in particular handles a practically
> unlimited number of controllers.  Support for devices with controllers
> that have active ACL connections requires other mesh devices to send
> more redundant packets to ensure delivery.
Ok, fair enough. We are well aware of performance considerations.

What I'm thinking about is having both modes of communication available,
even if the embedded device has just one Controller, as is the case with
the majority of off-the-shelf platforms.

The reason we want/need both BLE/GATT and Mesh on the same node has a
lot to do with provisioning - at the moment we configure our networks
using a mobile app, meaning we need devices to support PB-GATT. This is
because Controllers present in mobile devices do not support Mesh
natively, and we can't assume there is a GATT Proxy nearby, especially
when configuring a new network.

> And I am not opposed to someone starting a project that will allow the
> bluetoothd and meshd share a single controller and taking
> responsibility the reduced performance of each, but that is not work
> we have planned.
Ack.

FYI, it seems we might be interested in making that happen.

regards
-- 
Michał Lowas-Rzechonek <michal.lowas-rzechonek@silvair.com>
Silvair http://silvair.com
Jasnogórska 44, 31-358 Krakow, POLAND

  reply	other threads:[~2018-12-18 11:08 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-12-17 21:09 Plans for meshd Michał Lowas-Rzechonek
2018-12-17 21:48 ` Gix, Brian
2018-12-18 11:08   ` Michał Lowas-Rzechonek [this message]
2018-12-18 16:27     ` Gix, Brian
2018-12-18 17:07       ` Danielle Costantino
2018-12-18 17:24         ` Gix, Brian
2018-12-18 19:29       ` Michal Lowas-Rzechonek

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20181218110838.ollsqils5ci7cq4v@scytale \
    --to=michal.lowas-rzechonek@silvair.com \
    --cc=linux-bluetooth@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.