Thread (32 messages) 32 messages, 7 authors, 2012-06-11

Re: [PATCH] virtio-net: fix a race on 32bit arches

From: "Michael S. Tsirkin" <mst@redhat.com>
Date: 2012-06-06 20:43:43
Also in: lkml, virtualization

On Wed, Jun 06, 2012 at 09:35:04PM +0100, Ben Hutchings wrote:
On Wed, 2012-06-06 at 23:16 +0300, Michael S. Tsirkin wrote:
quoted
On Wed, Jun 06, 2012 at 10:08:09PM +0200, Eric Dumazet wrote:
quoted
On Wed, 2012-06-06 at 22:58 +0300, Michael S. Tsirkin wrote:
quoted
Absolutely, I am talking about virtio here.  I'm not kicking
u64_stats_sync idea I am just saying that simple locking
would work for virtio and might be better as it
gives us a way to get counters atomically.
Which lock do you own in the RX path ?
We can just disable napi, everything is updated from napi callback.
Seriously, though: don't do that; this is going to hurt performance for
minimal benefit.

Ben.
Yea, it doesn't work anyway. Maybe take a xmit lock for tx and keep
using the per-cpu counters for rx. Or does this sound too disruptive
too?
quoted
quoted
You'll have to add a lock in fast path. This sounds really a bad choice
to me.
.ndo_get_stats64 is not data path though, is it?
-- 
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help