From mboxrd@z Thu Jan  1 00:00:00 1970
Message-ID: <b0bc581700dd993447738444398bf038@quanstro.net>
From: erik quanstrom <quanstro@quanstro.net>
Date: Tue, 11 Aug 2009 16:21:19 -0400
To: 9fans@9fans.net
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Subject: [9fans] inaccurate etheroq accounting
Topicbox-Message-UUID: 4212783c-ead5-11e9-9d60-3106f5b1d025

i was looking to add bytes transmited to
/net/ether?/stats accounting but was derailed
because the existing accounting seems
inaccurate.

i'm pretty sure that etheroq can be called
concurrently on the same ether, so doesn't
that make the outpackets inaccurate at
high packet rates on an mp machine?

even if outpackets were not a vlong, it
would still be a seperate load and store
and meanwhile another processor could
have stored.

static int
etheroq(Ether* ether, Block* bp)
{
	int len, loopback, s;
	Etherpkt *pkt;

	ether->outpackets++;

for my public-facing 8169 chip operating
at a pitiful 10mbps, i do see evidence that
this really happens:

	out:	16703370	from stats (e.g. ether->outpackets)
	TxOk:	16607827	from the chip's accounting (ifstats)

(i'm pretty sure that lockstats.inglare and
friends in taslock.c have the same issue.)

in any event, it seems like there's got to
be a better way than adding a big fat lock
in the middle of the ether tx and rx paths.
seems like in the ether-specific functions
are going to lock things down at some point,
so maybe that accounting would be better
there?

- erik