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-next>] [day] [month] [year] [list]
Date:   Sun,  6 Mar 2022 09:56:52 +0100
From:   Gerhard Engleder <gerhard@...leder-embedded.com>
To:     richardcochran@...il.com, yangbo.lu@....com, davem@...emloft.net,
        kuba@...nel.org
Cc:     mlichvar@...hat.com, vinicius.gomes@...el.com,
        netdev@...r.kernel.org,
        Gerhard Engleder <gerhard@...leder-embedded.com>
Subject: [RFC PATCH net-next 0/6] ptp: Support hardware clocks with additional free running time

ptp vclocks require a clock with free running time for the timecounter.
Currently only a physical clock forced to free running is supported.
If vclocks are used, then the physical clock cannot be synchronized
anymore. The synchronized time is not available in hardware in this
case. As a result, timed transmission with ETF/TAPRIO hardware support
is not possible anymore.

If hardware would support a free running time additionally to the
physical clock, then the physical clock does not need to be forced to
free running. Thus, the physical clocks can still be synchronized while
vclocks are in use.

The physical clock could be used to synchronize the time domain of the
TSN network and trigger ETF/TAPRIO. In parallel vclocks can be used to
synchronize other time domains.

One year ago I thought for two time domains within a TSN network also
two physical clocks are required. This would lead to new kernel
interfaces for asking for the second clock, ... . But actually for a
time triggered system like TSN there can be only one time domain that
controls the system itself. All other time domains belong to other
layers, but not to the time triggered system itself. So other time
domains can be based on a free running counter if similar mechanisms
to 2 step synchronisation are used.

Synchronisation was tested with two time domains between two directly
connected hosts. Each host run two ptp4l instances, the first used the
physical clock and the second used the virtual clock. I used my FPGA
based network controller as network device. ptp4l was used in
combination with the virtual clock support patch set from Miroslav
Lichvar.

Please give me some feedback. For me it seems like a straight forward
extension for ptp vclocks, but I'm new to this topic.

Gerhard Engleder (6):
  bpf: Access hwtstamp field of hwtstamps directly
  ptp: Initialize skb_shared_hwtstamps
  ptp: Add free running time support
  ptp: Support time stamps based on free running time
  ptp: Allow vclocks without free running physical clock
  tsnep: Add free running time support

 .../net/ethernet/cavium/liquidio/lio_main.c   |  1 +
 .../ethernet/cavium/liquidio/lio_vf_main.c    |  1 +
 .../net/ethernet/chelsio/cxgb4/cxgb4_ptp.c    |  1 +
 drivers/net/ethernet/engleder/tsnep_hw.h      |  9 ++++--
 drivers/net/ethernet/engleder/tsnep_main.c    |  6 ++++
 drivers/net/ethernet/engleder/tsnep_ptp.c     | 28 +++++++++++++++++++
 .../hisilicon/hns3/hns3pf/hclge_ptp.c         |  1 +
 .../ethernet/mellanox/mlxsw/spectrum_ptp.c    |  1 +
 drivers/net/ethernet/sfc/tx_common.c          |  1 +
 drivers/ptp/ptp_clock.c                       |  8 +++---
 drivers/ptp/ptp_ines.c                        |  1 +
 drivers/ptp/ptp_private.h                     |  9 ++++++
 drivers/ptp/ptp_sysfs.c                       | 11 ++++----
 drivers/ptp/ptp_vclock.c                      | 25 +++++++++++++----
 include/linux/ptp_clock_kernel.h              | 27 ++++++++++++++++++
 include/linux/skbuff.h                        |  3 ++
 net/core/filter.c                             |  3 +-
 17 files changed, 117 insertions(+), 19 deletions(-)

-- 
2.20.1

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ