Hi, On Fri, Feb 19, 2016 at 10:17:54AM -0800, Greg Kroah-Hartman wrote: > 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. I'll send an updated patch that removes the atomic stuff. A. _______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
