[Top] [All Lists]

Re: netdev.stats change suggestion

To: kuznet@xxxxxxxxxxxxx
Subject: Re: netdev.stats change suggestion
From: "David S. Miller" <davem@xxxxxxxxxx>
Date: Thu, 24 Jan 2002 12:41:22 -0800 (PST)
Cc: netdev@xxxxxxxxxxx
In-reply-to: <200201242033.XAA11324@xxxxxxxxxxxxx>
References: <20020124.062650.66057933.davem@xxxxxxxxxx> <200201242033.XAA11324@xxxxxxxxxxxxx>
Sender: owner-netdev@xxxxxxxxxxx
   From: kuznet@xxxxxxxxxxxxx
   Date: Thu, 24 Jan 2002 23:33:56 +0300 (MSK)

   64bit counters create lots of troubles. Particularly, all the reads
   must be serialized wrt writes.
We have this serialization at the writes already.
Device is always locked in some way.  All that is
proposed is to formalize this.

Yes, I can see why we would not want to do this.
Your point has been heard.

   And I really do not see _any_ legal reasons to hold this kind
   of statistics in the kernel. I would even prefer that 64bit
   architectures used not "unsigned long" but u32.
   In fact, all that is required of statistics is to grow
   monotonically.  If it does, user level is more than happy. Look
   into iproute2, for example for ifstat, nstat and rtacct.
What if u32 wraps twice between snapshots?  I sense that your answer
imposes some requirement upon the user...  But when I run some command
line tool, I want it to tell me how many bazillion packets have gone
through my terabit ethernet interface since boot :-)

Aside from this, I really want to move all of these statistical things
towards netlink.  And I also want to do it in such a way that it is
painless to provide new counters.  All of this stuff is basically
string+u32 tuples so it can't be that difficult.

We could even expose the per-cpu nature of the counters (and even the
BH'icity) with a properly designed netlink interface.

<Prev in Thread] Current Thread [Next in Thread>