netdev
[Top] [All Lists]

Re: netdev.stats change suggestion

To: Donald Becker <becker@xxxxxxxxx>
Subject: Re: netdev.stats change suggestion
From: Jeff Garzik <jgarzik@xxxxxxxxxxxxxxxx>
Date: Fri, 25 Jan 2002 17:57:48 -0500
Cc: kuznet@xxxxxxxxxxxxx, Martin Devera <devik@xxxxxx>, davem@xxxxxxxxxx, netdev@xxxxxxxxxxx
Organization: MandrakeSoft
References: <Pine.LNX.4.10.10201251551080.743-100000@xxxxxxxxxxxxx>
Sender: owner-netdev@xxxxxxxxxxx
Donald Becker wrote:
> > Well, this attitude has grown as a kind of physiological reaction to
> > proposals sort of adding to struct net_device a Cisco-like
> > "interface desription" string.
> 
> Oooohhh, lets have a /proc/* file that describes the system in text.  An
> entire book, with only occasional dynamic values.

heh


> I do agree with the proposal to add to /proc/net/*
>     New per-interface statistics files that have only decimal numbers
>        A program that is only interested in one interface won't trigger
>        re-reads of all interfaces.

As long as these numbers can be larger than ULONG_MAX on a 32-bit
machine, sure...


>     A new (static, read-once) file that describes contains text field labels

Anything but procfs, really.  :)  It's a jumbled mess of crud, and I
would not be surprised if viro managed kill large portions of it during
the 2.5 cycle.

To tangent, whether viro creates it or we do, I imagine we will end up
with 'netfs' filesystem or somesuch, which contains pretty much the same
contents as /proc/net/* now.  Per-if stats files would be a good
candidate for such an fs :)  Such a solution would be both forward and
backwards compatible, too [just backport netfs to 2.2, etc.]


> The idea to mmap() that statistics file has issues:
>    We need a timestamp for the reader
>    We need a way for the reader to trigger a hardware update
>      (Currently reading /proc/net/dev does this.)
>    We might need a mechanism so that multiple readers can read
>      stable/synchronized values.

mmap'ing statistics is a pretty nice idea, though I'm not sure how one
could implement this with the requirements you list, and still maintain
performance.  [sure, arch-specific hacks like r/w-protecting a page
would make this possible, but such a solution would not be completely
portable]

Attaching a page to an inode [at inode creation time], and read(2)ing
through the page cache should provide near-same performance while being
able to handle the requirements you mention.

More in the response to Alexey...

Regards,

        Jeff


-- 
Jeff Garzik      | "I went through my candy like hot oatmeal
Building 1024    |  through an internally-buttered weasel."
MandrakeSoft     |             - goats.com

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