netdev - Re: [net-next PATCH 29/29] fm10k: Add support for PTP

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Sat, 20 Sep 2014 16:36:45 -0700
From:	Alexander Duyck <alexander.duyck@...il.com>
To:	Richard Cochran <richardcochran@...il.com>,
	Alexander Duyck <alexander.h.duyck@...el.com>
CC:	davem@...emloft.net, nhorman@...hat.com, netdev@...r.kernel.org,
	john.fastabend@...il.com, matthew.vick@...el.com,
	jeffrey.t.kirsher@...el.com, sassmann@...hat.com
Subject: Re: [net-next PATCH 29/29] fm10k: Add support for PTP

On 09/20/2014 02:16 PM, Richard Cochran wrote:
> On Fri, Sep 19, 2014 at 11:32:24AM -0700, Alexander Duyck wrote:
>> Because the value cannot be adjusted directly.  The timesource for the
>> switch is shared by all ports and host interfaces.  As such we have to
>> maintain a software offset per host to avoid corrupting the other clocks.
> So any host can set the time, but only one may adjust the frequency?

Yes.  Essentially the one who should be adjusting the frequency should
be the host interface that is providing traffic for the control plane
processor.  That way the control plane processor can act as a boundary
clock and can adjust the frequency to match the port it has decided to
be a slave on.

In the case of the ordinary clock host interfaces they will be slaves to
the boundary clock and since they share the same clock source anyway
they shouldn't need any frequency adjustments, or at least that is how
it is supposed to work.  The other reason for using the software offset
is that it can be very time intensive as you have to stop the clock,
update the staring value for each host interface and the Ethernet ports,
and then you can resume the clock.  It can be a rather time consuming
process doing it that way versus just maintaining an offset in software.

Tx timestamps from the host interface are actually identical to the Rx
timestamps on the receiving host interface in the case of traffic going
between two fm10k host interfaces on the same switch.  So what you end
up with is that any two hosts should be able to perfectly synchronize
their clocks with just the follow-up to the first sync message.  I've
done some testing for this with an FPGA and actually it has proven out
as ptp4l did one offset adjustment on the follow-up and then indicated 0
adjustments from there forward.  It is one of the reasons why I believe
we should be able to disable the frequency adjustment for interfaces
configured as ordinary clocks.

> Regarding the overflow, probably you can remove the daily check, since
> you only need a single clock read every 300 years, and that is
> reasonable to expect in any case.

Yeah, I figured that out after I recalled that the overflow check is
only really necessary if the mask is less than 64 bits.

Thanks,

Alex

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html