On Fri, Feb 19, 2016 at 10:08:07AM -0800, David Daney wrote: > On 02/18/2016 03:45 PM, Greg Kroah-Hartman wrote: > >On Fri, Feb 19, 2016 at 12:20:45AM +0200, Aaro Koskinen wrote: > >>Use atomic_long_t, so that we can avoid some 32 vs. 64-bit ifdeffery. > > > >Why are these atomic at all? There's no reason they can't just be a > >u64 like all other network drivers have, right? > > In the original code, they were incremented by multiple threads/CPUs, so > atomic operations perform better than putting a spinlock around the whole > thing. > > If the invariant holds that there is exactly one napi_struct per net_device, > then the atomic business may not be necessary. There is still the > possibility of whatever is reading the statistics racing with the update, > but perhaps that doesn't matter. I don't think that matters, the stats are there just to see what is happening at a macro level, look at all of the other network drivers in the kernel, they don't need a lock or an atomic type for this type of statistic from what I can tell. thanks, greg k-h _______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
