Re: [PATCH net V4 2/2] igb: offer a PTP Hardware Clock instead of the timecompare method
From: chetan loke <hidden>
Date: 2012-03-26 19:32:08
On Mon, Mar 26, 2012 at 2:56 PM, Keller, Jacob E [off-list ref] wrote:
I am curious how you see a kernel thread resolving the Tx/Rx issue? or is the kernel thread being used by gettime? I don't believe we can wait for the Tx/Rx
tx, rx path and kernel thread will use seq_lock_isave(tmreg_lock). A new 'u64 cached_ns' will be introduced. tx and rx path can update 'cached_ns' when they read the NIC counter. A kernel-thread should be scheduled periodically, will read the NIC counter and update cached_ns. It will use a _trylock variant. If the lock fails then its a hint that 'cached_ns' is getting updated somewhere, so just refresh the timer. Periodic update is needed to handle idle/bursty link conditions because the Rx/tx path may not run that often. gettime uses read_seq_lock and reads 'cached_ns'. I mean we could also do a atomic_read(?).
path, because if we take too long the software sees it as a dropped timestamp.
What code-path is this?
How would we only allow one app? Any app with permissions could call the ioctls. I do agree that having too many ioctls is a problem. Even in cases where PTP is
We don't. So this is what I'm thinking. Ideally speaking only 1 app should be adjusting the host-clock and 1 app per NIC if you adjust NIC's clock. Ignore the host-clock app. Once you enforce the rate-limit, driver will return -EBUSY if you exceed it. Too many EBUSYs will provide a hint on user-side. 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® Ethernet, visit http://communities.intel.com/community/wired