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

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

This commit removes the legacy timecompare code from the igb driver and
offers a tunable PHC instead.

Richard (and others who contributed),

This ptp stuff is great work(time-sync sources, pkt-time,
system-time)! Now, I've a few questions :) :

1) how can I use igb->PHC to set/discipline my system time?
 a) clock_gettime(IGB_CLK_ID...);
 b) clock_settime(REAL_TIME,...) ? Good/bad idea?

2) what is this deadlock from intel's datasheet
(http://download.intel.com/design/network/datashts/82576_Datasheet.pdf)
- goto pg 426
  2.1) Is this applicable? If not please ignore this question.
  2.2) Do we need to worry about it. Just asking because a quick
visual scan didn't pull up - TIMADJL/H.

3) Testing IGB PHC (couple of months from now because I'm busy with
something else):

   3.1) CardX(It's a different non-intel NIC) and CardY(intel) are in
hostA. Both cards will use the same time-source Z.
   3.2) CardX is time-sync'd using PTP.
   3.3) CardY - is a dual port card. Port 0 will receive PTP packets
via time-srcZ.
   3.4) Wait for some time for both the cards to get in-sync.
   3.5) feed same traffic to Card X and CardY-Port1.
   3.6) measure time-difference across packets from different NICs on hostA.

   Is this a good test configuration? Now, ofcourse there will be some
delta but the intention is to get a feel. See how far off are both the
adapters.

4) possible contention on tmreg_lock?
I will read previous emails/patches shortly but I was thinking - what
if there are many readers who would like to use PHC as reference time?
Then do we want them to block the driver who wants to time-stamp the
packet?
 igb_gettime->spin_lock::tmreg_lock         <---contention--->  driver
->igb_systim_to_hwtstamp->spin_lock::tmreg_lock


thanks
Chetan