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  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:   Wed, 5 Jun 2019 21:08:54 +0300
From:   Vladimir Oltean <olteanv@...il.com>
To:     Richard Cochran <richardcochran@...il.com>
Cc:     David Miller <davem@...emloft.net>,
        Florian Fainelli <f.fainelli@...il.com>,
        Vivien Didelot <vivien.didelot@...il.com>,
        Andrew Lunn <andrew@...n.ch>,
        John Stultz <john.stultz@...aro.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Stephen Boyd <sboyd@...nel.org>,
        lkml <linux-kernel@...r.kernel.org>,
        netdev <netdev@...r.kernel.org>
Subject: Re: [PATCH v3 net-next 00/17] PTP support for the SJA1105 DSA driver

On Wed, 5 Jun 2019 at 20:45, Richard Cochran <richardcochran@...il.com> wrote:
>
> On Wed, Jun 05, 2019 at 02:33:52PM +0300, Vladimir Oltean wrote:
> > In the meantime: Richard, do you have any objections to this patchset?
>
> I like the fact that you didn't have to change the dsa or ptp
> frameworks this time around.  I haven't taken a closer look than that
> yet.
>

There's one more thing I wanted to ask you if you get the chance to
take a closer look.
Currently I'm using a cyclecounter, but I *will* need actual PHC
manipulations for the time-based shaping and policing features that
the switch has in hardware. On the other hand I get much tighter sync
offset using the free-running counter than with hardware-corrected
timestamps. So as far as I see it, I'll need to have two sets of
operations.
How should I design such a dual-PHC device driver? Just register two
separate clocks, one for the timestamping counter, the other for the
scheduling/policing PTP clock, and have phc2sys keep them in sync
externally to the driver? Or implement the hardware corrections
alongside the timecounter ones, and expose a single PHC (and for
clock_gettime, just pick one of the time sources)?

> > I was wondering whether the path delay difference between E2E and P2P
> > rings any bell to you.
>
> Can it be that the switch applies corrections in HW?
>
> Thanks,
> Richard

Thanks,
-Vladimir

Powered by blists - more mailing lists