On Wed, Jun 06, 2012 at 07:13:02PM +0200, Eric Dumazet wrote:
On Wed, 2012-06-06 at 19:17 +0300, Michael S. Tsirkin wrote:
quoted
But why do you say at most 1 packet?
Consider get_stats doing:
u64_stats_update_begin(&stats->syncp);
stats->tx_bytes += skb->len;
on 64 bit at this point
tx_packets might get incremented any number of times, no?
stats->tx_packets++;
u64_stats_update_end(&stats->syncp);
now tx_bytes and tx_packets are out of sync by more than 1.
You lost me there.
No idea of what you are thinking about.
Sorry about that. This is not a bug. I am saying two things:
1. We are trying to look at counters for purposes of tuning the device.
E.g. if ethtool reports packets and bytes, we'd like to calculate
average packet size by bytes/packets.
If both counters are read atomically the metric becomes more exact.
Not a must but nice to have.
2. 32 bit systems have some overhead because of the seqlock.
virtio could instead simply keep tx counters in the queue structure, and
get the tx lock when they are read.
--
MST
On Wed, 2012-06-06 at 21:43 +0300, Michael S. Tsirkin wrote:
1. We are trying to look at counters for purposes of tuning the device.
E.g. if ethtool reports packets and bytes, we'd like to calculate
average packet size by bytes/packets.
If both counters are read atomically the metric becomes more exact.
Not a must but nice to have.
metrics are exact right now.
As soon as you read a value, it might already have changed.
Maybe you want to stop_machine() to make sure all the metrics you want
are 'exact' ;)
2. 32 bit systems have some overhead because of the seqlock.
virtio could instead simply keep tx counters in the queue structure, and
get the tx lock when they are read.
But then you need atomic64 stuff, have you an idea of the cost of such
primitives on 32bit ?
3. use 32bit counters on 32bit arches, as many drivers still do ?
On Wed, Jun 06, 2012 at 10:06:11PM +0200, Eric Dumazet wrote:
On Wed, 2012-06-06 at 21:43 +0300, Michael S. Tsirkin wrote:
quoted
1. We are trying to look at counters for purposes of tuning the device.
E.g. if ethtool reports packets and bytes, we'd like to calculate
average packet size by bytes/packets.
If both counters are read atomically the metric becomes more exact.
Not a must but nice to have.
metrics are exact right now.
Yes, but they are not synchronised between themselves.
E.g. you can in theory have a report where #of packets > #of bytes.
I know there's no guarantee they are synchronised
on an arbitrary device but if they are, without
slowing fast path, it's nice.