Move if_opackets++ to where if_obytes are

[Ryota Ozaki]

Hi,

I propose to move if_opackets from device drivers to where
if_obytes is incremented (not just one place), for example
in if_transmit.

The aims of the change are:
- Unify how it's incremented
- Usages of the counter are different between device
drivers
- There are roughly two places to count it up;
(1) when a packet is dequeued from if_snd (in
XXX_start function) and (2) when a packet is
successfully transmitted (in Tx interrupt)
- Users normally expect the counter is incremented in the
same manner between device drivers
- It is hard to unify the behavior while having the counter
in each device driver
- Synchronize with if_obytes
- Users normally expect if_opackets and if_obytes are
synchronized, but they aren't now
- It is hard to do so while having the two counters in
different places
- Simplify the code
- We can reduce the number of places doing if_opackets++

Some concerns on the change:
- The meaning/behavior of the counter is changed
- From "the number of packets sent on the interface" to
"the number of packets passed to the interface to send"
- But if_obytes is ever like that
- if_oerrors isn't moved (at least in this change)
- It is hard to count errors happening in a device
driver outside the device driver
- We can count the number of dropped packets at the if_snd
queue but that's perhaps not what we want to know
by if_oerrors
- That aside IMO errors happening in a device driver should
be counted by driver own statistic counters and be
reported via sysctl, evcnt or the like
- So we can know what kind of errors happened, not just
some sort of errors happened

This is a patch of the change:
http://www.netbsd.org/~ozaki-r/move-if_opackets.diff

The patch includes only changes for sys/net*, wm(4) and
vioif(4). Changes for other drivers will be made once the
proposal is accepted.

Any comments or suggestions?

Thanks,
ozaki-r

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Michael van Elst]

Post by Ryota Ozaki
- Users normally expect the counter is incremented in the
same manner between device drivers

Drivers only count packets, because that's what the hardware (originally)
provides and that's what the driver API supports. The counts resemble
what is actually on the wire. For hardware that doesn't provide statistic
counters this is usually done in software by counting interrupts or
processed DMA buffers in the driver.
The other counters (e.g. errors, collision, etc..) are also all
provided or derived by the hardware.

The network interface layer that assembles and disects packets
counts bytes. That's bytes queued for sending or retrieved from
the queue. It's also information that the hardware or the driver
usually don't have and the ibytes/obytes values were added later
to the code to make that information available.

It's easily possible to have multiple packet counts for the same
chunk of bytes if something went wrong with the transmission
in either direction. So packet and byte counters aren't necessarily
in sync.

I'm not sure if users would expect a changed behaviour.

So instead of dropping the hardware information and pretending its
all data from the network layer, maybe the opposite is better.
Provide byte counts by the driver so that it stays "in-sync" with
the packet counts and add a new API to get per-interface statistics
from the network layer.