Re: RFC: NetworkManager Device Statistics

[Dan Williams <dcbw redhat com>]

On Thu, 2016-05-26 at 07:53 +0200, Alfonso Sanchez-Beato wrote:
> On Thu, May 26, 2016 at 1:44 AM, Tony Espy <espy canonical com>
> wrote:
>
> > On 05/25/2016 12:45 PM, Dan Williams wrote:
> >
> > > On Wed, 2016-05-25 at 18:10 +0200, Thomas Haller wrote:
> > >
> > > > On Tue, 2016-05-24 at 12:51 -0400, Tony Espy wrote:
> > > >
> > > > > We have a new requirement to add a data activity indicator to
> > > > > Ubuntu
> > > > > Touch for certification in certain markets.
> > > > >
> > > > > We've had some internal debate about whether or not we should
> > > > > extend
> > > > > NetworkManager to provide this information to the rest of the
> > > > > system
> > > > > vs.
> > > > > adding logic directly to our touch-specific network
> > > > > indicator.
> > > > Hi Tony,
> > > >
> > > >
> > > > IMO it would be interested in having this in NetworkManager,
> > > > and I
> > > > think we would be willing to help with implementation.
> > > Yeah, it's been brought up before and it just needed somebody to
> > > do it
> > > :)
> > Cool.  We're on it then!
> >
> > As with the previous reply, CC'd Alfonso.
> >
> > The current prototype is based on a similar facility in Connman,
> > > > > and
> > > > > involves RTM_GETLINK polling to retrieve device-specific Rx
> > > > > and Tx
> > > > > statistics.
> > > > Do you have a prototype available somewhere?
> > > >
> > > >
> > > >
> > > > > Connman's API can be seen here:
> > > > >
> > > > > https://git.kernel.org/cgit/network/connman/connman.git/tree/
> > > > > doc/co
> > > > > un
> > > > > ter-api.txt
> > > > > https://git.kernel.org/cgit/network/connman/connman.git/tree/
> > > > > doc/ma
> > > > > na
> > > > > ger-api.txt#n90
> > > > >
> > > > > Our proposed implementation involves extending
> > > > > NMPlatform/NMLinuxPlatform and adding some new properties to
> > > > > the
> > > > > NetworkManager.Device interface:
> > > > >
> > > > > * TxBytes, TxPackets, [calculated TxRate (byte/s)] and Rx
> > > > > equivalents
> > > > > * EnableStatProps : boolean property to enable/disable device
> > > > > statistics
> > > > > * StatPropsRefreshRateMs : refresh rate for Tx/Rx properties
> > > > > in
> > > > > milliseconds
> > > > >
> > > > > An alternative to extending the Device interface would be
> > > > > adding a
> > > > > dedicated Device.Statistics interface; and perhaps a Device
> > > > > interface
> > > > > method ( vs. the EnableStatProps property ) to control
> > > > > enabling/disabling collection of statistics on a per-device
> > > > > basis.
> > > > >
> > > > > The idea behind EnableStatProps is to avoid overloading the
> > > > > system
> > > > > with
> > > > > PropertiesChanged signals. The Tx/Rx properties will not
> > > > > refresh
> > > > > if
> > > > > EnableStatProps is false, and will refresh, sending
> > > > > PropertiesChanged
> > > > > signals with the rate specified in StatPropsRefreshRateMs,
> > > > > when
> > > > > true.
> > > > > In our case, we'd explicitly disable statistics when the
> > > > > screen on
> > > > > a
> > > > > device is turned off.
> > > > Maybe EnableStatProps could be dropped, and is implicit by
> > > > setting StatPropsRefreshRateMs to zero.
> > > I would say that the new Device.Statistics interface would simply
> > > have
> > > a "RefreshRateMs" property (eg, no StatProps prefix) which would
> > > be set
> > > to > 0 to enable reporting via D-Bus.  Then have the Tx/Rx
> > > statistics
> > > as properties of the interface as well, that stay zero when
> > > reporting
> > > isn't enabled or is turned off.
> > Sounds like a good approach to me.  Alfonso?
>
> Sounds sensible to me, let's go this way.

One other aspect I thought of are PPP stats.  NM periodically
polls SIOCGPPPSTATS but currently doesn't do anything with that result.
 Are the numbers from SIOCGPPPSTATS different than the numbers that we
can pull out of the pppX netdevice generically?

There's also the flow reporting that some WWAN devices do, I'm thinking
of Huawei here specifically with their DSFLOWRPT notifications.  I also
wonder if those would be more accurate than looking at packet stats on
the netdevice.

In the end, all these numbers are just estimations anyway, and having a
generic mechanism that just reads stats off the netdevice would be a
great start.  Maybe that means we can kill the SIOCGPPPSTATS code too
:)

Dan