netdev - Re: [net-next 0/6] ptp: support virtual clocks for multiple domains

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]

Message-ID: <20210510231832.GA28585@hoboy.vegasvil.org>
Date:   Mon, 10 May 2021 16:18:32 -0700
From:   Richard Cochran <richardcochran@...il.com>
To:     "Y.b. Lu" <yangbo.lu@....com>
Cc:     "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "David S . Miller" <davem@...emloft.net>,
        Claudiu Manoil <claudiu.manoil@....com>,
        Jakub Kicinski <kuba@...nel.org>
Subject: Re: [net-next 0/6] ptp: support virtual clocks for multiple domains

On Mon, May 10, 2021 at 03:04:39AM +0000, Y.b. Lu wrote:

> There may be some misunderstanding. In the example, domain 1, 2, 3 are based on PTP virtual clocks ptp1, ptp2 and ptp3 which are utilizing their own timecounter.
> The clock adjustment on them won't affect each other. The example worked fine in my verification.

Okay, now I think I understand what you are suggesting.  Still, there
are issues you haven't considered.

> I mean if the physical clock keeps free running, all virtual clocks utilizing their own timercounter can work fine independently without affecting on each other.

Right.  This is critical!

> If the physical clock has change on frequency, there is also way to make the change not affect virtual clocks.
> For example, when there is +12 ppm change on physical clock, just give -12 ppm change on virtual clocks.

That will cause issues in very many cases.

For example, what happens when the "real" clock sees a large offset,
and it doesn't step, but rather applies the maximum frequency offset
to slew the clock?  That maximum might be larger that the max possible
in the virtual clocks.  Even with smaller frequency offsets, the
un-synchronized, quasi random changes in the "real" clock will spoil
the virtual clocks.  I won't support such an approach.

However, if the "real" clock is guaranteed to stay free running, and
the virtual clocks give up any hope of producing periodic outputs,
then your idea might work.

Thinking out loud: You could make a sysfs knob that converts a "real"
clock into two or more virtual clocks.  For example:

    cat /sys/class/ptp/ptp0/number_vclocks
    0 # ptp0 is a "real" clock

    echo 3 > /sys/class/ptp/ptp0/number_vclocks
    # This resets the frequency offset to zero and creates three
    # new clocks using timecounter numeric adjustment, ptp0, 1, and 2.
    # ptp0 loses its periodic output abilities.
    # ptp0 is now a virtual clock, just like ptp1 and 2.

    echo 0 > /sys/class/ptp/ptp0/number_vclocks
    # back to normal again.

In addition to that, you will need a way to make the relationships
between the clocks and the network interfaces discoverable.

It needs more thought and careful design, but I think having
clock_gettime() available for the different clocks would be nice to
have for the applications.

Thanks,
Richard