-----Original Message-----
From: Richard Cochran [mailto:richardcochran@gmail.com]
Sent: Tuesday, March 27, 2012 11:05 AM
To: Keller, Jacob E
Cc: chetan loke; netdev@vger.kernel.org; e1000-devel@lists.sourceforge.net;
Kirsher, Jeffrey T; Ronciak, John; john.stultz@linaro.org; tglx@linutronix.de
Subject: Re: [PATCH net V4 2/2] igb: offer a PTP Hardware Clock instead of the
timecompare method

I really doubt you will see any performance gain from such a change. It
increases code complexity and size for some dubious, theoretical performance
gain, for some really whacked use case.

Richard

It isn't so much about performance gains as it is about preventing poorly written user apps from stalling the clean descriptor routines. I am working on a test case that should prove whether this is even an issue (at least with ixgbe). Once I have data on that it can be determined if the extra lock would alleviate it. The conceptual issue is that spamming get-time could cause the clean tx/rx irq routines to stall inside the interrupt for too long. (thereby not freeing up descriptors on the ring to allow more packets). While performance is an issue, I don't feel that it can be brushed off as "performance loss due to feature" unless I can show that it isn't very easy to trip, or doesn't cause a major issue. Once I know the data, it can be determined what the right approach is.