[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1289426017.2249.56.camel@achroite.uk.solarflarecom.com>
Date: Wed, 10 Nov 2010 21:53:37 +0000
From: Ben Hutchings <bhutchings@...arflare.com>
To: Eric Dumazet <eric.dumazet@...il.com>
Cc: Ben Greear <greearb@...delatech.com>,
David Miller <davem@...emloft.net>,
Patrick McHardy <kaber@...sh.net>,
netdev <netdev@...r.kernel.org>
Subject: Re: [PATCH] macvlan: lockless tx path
On Wed, 2010-11-10 at 22:12 +0100, Eric Dumazet wrote:
> Le mercredi 10 novembre 2010 à 21:04 +0000, Ben Hutchings a écrit :
>
> > Drivers should calculate differences and accumulate them in a 64-bit
> > counter. (A lot of hardware has read-to-clear counters anyway, in which
> > case the driver *has* to accumulate the values it reads.)
>
> You are mistaken. These are _hardware_ counters. If they were software,
> of course they would be 32 or 64 bit.
Of course I understood that.
> And doing the thing you describe in software is racy.
> I tried to remove many races, not to add new ones.
If you do it in ndo_get_stats{,64} and don't use your own lock, yes.
> Yes, some drivers read one hardware counter using two instructions, and
> this is racy.
Most hardware which supports MMIO to multi-word counters has some kind
of latching scheme where you can read the words/registers in order and
get consistent values (within a single counter; consistency between
counters is another matter). Obviously you have to use a lock to
serialise stats updates in this case - whether or not you maintain wider
software counters.
Oh, another problem with using register values directly is that
statistics are likely to be reset whenever the device is reconfigured in
the way that requires a hardware reset.
Ben.
--
Ben Hutchings, Senior Software Engineer, Solarflare Communications
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists