Re: [PATCH v1] net-sysfs: expose number of link up/down transitions

[Florian Fainelli]

2014-03-28 10:46 GMT-07:00 Eric Dumazet <eric.dumazet@xxxxxxxxx>:
> On Fri, 2014-03-28 at 09:51 -0700, Florian Fainelli wrote:
>> 2014-03-27 23:25 GMT-07:00 Jiri Pirko <jiri@xxxxxxxxxxx>:
>> >
>> > If this is exposed in sysfs, this needs to be exposed via RT netlink as
>> > well.
>>
>> This makes me wonder if this really needs to be a kernel-maintained
>> pair of counters. Since this seems to be useful for monitoring e.g:
>> servers for link flapping, I would assume that some user-space
>> script/program does read these sysfs entries periodically to report a
>> healthy link. If that's the case, what prevents the same
>> script/program from listening to netlink events and count the link
>> UP/DOWN events from there and report that?
>
> The same would be true for any counter in networking stack...
>
> I do not feel we need to have a daemon running to 'count' events.
>
> I like being able to run "ip -s link" , "ifconfig -a" or "nstat -a"
> without having to connect to a daemon. This daemon will likely have
> different api / constraints from distro to distro.
>
> To me, first thing is a counter, then eventually events for daemons.

What I meant is that this sort of information most likely is already
part of some sort of machine health check that runs periodically,
which probably collects gazillions of other metrics. Whether the link
flapping information comes from sysfs or was maintained by a small
script which counts link UP/DOWN events from 'ip monitor link' and
outputs this into a file boils down to the same thing: the information
is available to some degree.

That said, this is a cheap pair of a counter in a slow path, so maybe
it is fine to have it without requiring any user-space dependency to
be read...

>
> drop_monitor could eventually disappear if we had counters everywhere we
> need them.
>
>
>



-- 
Florian
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/