Thread (37 messages) flat view 37 messages, 3 authors, 2012-03-30

Re: [PATCH net V4 2/2] igb: offer a PTP Hardware Clock instead of the timecompare method

From: chetan loke <hidden>
Date: 2012-03-27 18:43:11

On Tue, Mar 27, 2012 at 2:29 PM, Keller, Jacob E
[off-list ref] wrote:
quoted
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
What would be interesting to see is something like:

1) App1(getter/setter calls), executed '1000' ioctls per sec on eth0.
Other 'M' apps(execute just get calls), where M = 1 .. 10(?). And one
buggy app executed - 10K getter calls per sec.

2) eth0 receives PTP traffic and also around 80-90%(link rate)
regular/mixed traffic.

And BTW, eth0 is the management IP.

While the test is running, if we are still able to reach the host and
manage it via SSH then we can stop being paranoid.


Chetan

------------------------------------------------------------------------------
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here 
http://p.sf.net/sfu/sfd2d-msazure
_______________________________________________
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel&#174; Ethernet, visit http://communities.intel.com/community/wired
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help