Le mardi 13 décembre 2011 à 04:41 +0100, Richard Cochran a écrit : > On Tue, Dec 13, 2011 at 04:28:52AM +0100, Eric Dumazet wrote: > > > > Adding a (shared) spinlock on a multiqueue device is source of extra > > delay (because of extra cache line trafic), I guess. > > > > It seems current code doesnt need a spinlock, maybe it was a bug ? > > (I didn't think about the old code. I only deleted it. ;) > > The spinlock is needed because reading the 64 bit time value involves > reading two 32 registers. The first read latches the value. Ditto for > writing. > > In addition, here we have to watch the most significant bit for > one-to-zero transistion, in order to keep count of the overflow. > > It is too bad that we have to take the spinlock for every time stamped > packet, but it is the hardware's fault for not providing a 64 bit wide > nanosecond time register. >
Yes, probably. Are you sure a workaround is not possible, using a seqlock for synchronization of threads, and two hardware reads ? Or maybe it doesnt matter at all :) ------------------------------------------------------------------------------ Systems Optimization Self Assessment Improve efficiency and utilization of IT resources. Drive out cost and improve service delivery. Take 5 minutes to use this Systems Optimization Self Assessment. http://www.accelacomm.com/jaw/sdnl/114/51450054/ _______________________________________________ E1000-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/e1000-devel To learn more about Intel® Ethernet, visit http://communities.intel.com/community/wired
