Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 09 Jun 2002 05:21:56 -0700
From:      Terry Lambert <tlambert2@mindspring.com>
To:        Andre Oppermann <oppermann@pipeline.ch>
Cc:        Andy Sparrow <spadger@best.com>, Larry Rosenman <ler@lerctr.org>, freebsd-net@FreeBSD.ORG, freebsd-hackers@FreeBSD.ORG
Subject:   Re: MIB support for network devices in FreeBSD?
Message-ID:  <3D034864.BC63469C@mindspring.com>
References:  <20020609035146.55A8F3E2D@CRWdog.demon.co.uk> <3D02E7F4.432854D0@mindspring.com> <3D032AE7.8B8CB2A@pipeline.ch>

next in thread | previous in thread | raw e-mail | index | archive | help
Andre Oppermann wrote:
> > Benchmark the driver.
> >
> > If it's fast, it doesn't collect the statistics.
> 
> Come on, this is bullshit. whatever++ hardly makes any difference.
> There are other places where way more cycles are wasted for less.

You removed my "8-)" by truncating my statement, and seperating it
out.

However, if you're going to be insistant, my statement was really
like foam rubber duct taped to an aluminum baseball bat: a core of
truth wrapped in humor, so it didn't hurt as much.


Without the atomic increment code that John Baldwin and Julian
Elisher have asked to be adopted time and again, each place you
increment has to lock, increment, then unlock the interface
statistics structure.

Similar locks occur on the global statistics, which are contended
between all interfaces, rather than aggregated out of per interface
statistics, with no locking whatsoever (like "ps", they are a
snapshot of system state; the only accuracy needs to be in their
incrementing, not in their instantaneous value).  The upshot is
serialization of routing and/or multicast on multiple interface
systems.

You end up having to implement increment locking in any case, if
you insist on your snapshot, even for a single interface, have
inter-element consistency for the aggregate of all values for a
given interface (you must write lock so that writing respects
the read lock, since writes are per elemenet, and reads are
per aggregate).

This is particularly true for "bad packet" counters, where the
decision about what constitutes a bad packet is most often made
by higher protocol layers, and thus is not intrinsically "per
interface" -- worse, they run at NETISR in 4.x, and are expected
to run in an interrupt thread, in 5.x.

Getting rid of NETISR entirely (*not* replacing it with interrupt
threads running the stack) would get rid of the contention, in
that there would be implicit locking of the structure, were it
per interface.  You'd still need to aggregate it for global stats
(e.g. the output of "netstat -s"), but, per above, that would not
require locking, since it's a read-only operation, and is
statistical in natures.

For statistics, read locking implies write locking which implies
locking on every update operation, even when the vast majority of
times there is no possiblity of contention, because no one really
cares about the stats values, for the most part.  If you insist
on exactitude, then you end up seperately serializing all
statistics updates -- after all, statistics are gathered as the
result of conditions which are rarely simultaneously handled in
the code.

Most of the stuff the original post wanted to monitor is not
really defined for STD-0050 (RFC-1643), RFC-2665 or RFC-3201.

Further, interface statistics are peculiar to the abstract
concept "interface", and should have nothing whatsoever to do
with the driver.  If there is explicit driver support required,
then there is an intrinsic problem, in that the MIB elements in
question are not uniform across drivers for real hardware reasons,
not just because someone forgot to add them.

Probably, it would be good to implement them at a higher
"interface layer", on top of all drivers.  Bill Paul and Archie
Cobbs would bot be good people to involve in any discussion, but
to me, it makes no sense to modify individual drivers to resolve
the original issue, rather than writing common code once, in
lieu of replicating (hopefully) identical code in a grundle of
drivers.


The real answer should have been "For what purpose are these
statistics to be gathered?", particularly since a many of
them are in fact not RFC mandated for Interfaces, and are really
only valuable in particular application domains (and may have
their own MIBs for those domains, e.g. Frame Relay, DSL, or
802.12, etc..


So if you want to be picky, let me change my answer:

For what purpose are these statistics to be gathered?

-- Terry

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3D034864.BC63469C>