[RFC BlueZ] mesh: Alternative delivery method of mesh packets

[RFC BlueZ] mesh: Alternative delivery method of mesh packets

[Michał Lowas-Rzechonek]

Hi Inga, Brian,

When playing with bluetooth-meshd on an embedded platform (i.MX6 UL),
I've noticed an unusually high CPU load, both on user and system levels.

Granted, our application is implemented in Python, so it's not the most
performant language for ARM (to be gentle), but I still think it should
be able to handle the message load... For the record, the traffic we're
subscribing to is about 100 messages per second, published by 200+
nodes.

I don't have hard data to back this up, but I've profiled the
application and it seems that most of the CPU time is spent on D-Bus
marshalling. I also suspect that most of the 'system' time is spent
passing message buffers between bluetooth-meshd, dbus-daemon and the
application.

To make things worse, the platform we're using imposes tight security
constraints, to the point where it inspects each and every D-Bus call
using AppArmor.

All of that makes  me wonder if we shouldn't optimise message transport,
by e.g. passing a datagram socket descriptor that applications can
recvmsg() from, avoiding method calls over D-Bus, like
org.bluez.GattCharacteristic1.AcquireNotify.

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