2020-05-20 16:18:50

by Michał Lowas-Rzechonek

[permalink] [raw]
Subject: [RFC BlueZ] mesh: Alternative delivery method of mesh packets

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 <[email protected]>
Silvair http://silvair.com
Jasnogórska 44, 31-358 Krakow, POLAND