[net-next,v3,0/6] ptp: Support hardware clocks with additional free running cycle counter

Message

Gerhard Engleder May 1, 2022, 11:18 a.m. UTC

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 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 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
like 2 step synchroisation 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 patches from Miroslav
Lichvar.

v3:
- optimize ptp_convert_timestamp (Richard Cochran)
- call dev_get_by_napi_id() only if needed (Richard Cochran)
- use non-negated logical test (Richard Cochran)
- add comment for skipped output (Richard Cochran)
- add comment for SKBTX_HW_TSTAMP_USE_CYCLES masking (Richard Cochran)

v2:
- rename ptp_clock cycles to has_cycles (Richard Cochran)
- call it free running cycle counter (Richard Cochran)
- update struct skb_shared_hwtstamps kdoc (Richard Cochran)
- optimize timestamp address/cookie processing path (Richard Cochran,
  Vinicius Costa Gomes)

v1:
- complete rework based on suggestions (Richard Cochran)

Gerhard Engleder (6):
  ptp: Add cycles support for virtual clocks
  ptp: Request cycles for TX timestamp
  ptp: Pass hwtstamp to ptp_convert_timestamp()
  ptp: Support late timestamp determination
  ptp: Speed up vclock lookup
  tsnep: Add free running cycle counter support

 drivers/net/ethernet/engleder/tsnep_hw.h   |  9 ++-
 drivers/net/ethernet/engleder/tsnep_main.c | 33 +++++++--
 drivers/net/ethernet/engleder/tsnep_ptp.c  | 28 ++++++++
 drivers/ptp/ptp_clock.c                    | 31 ++++++--
 drivers/ptp/ptp_private.h                  | 11 +++
 drivers/ptp/ptp_sysfs.c                    | 11 +--
 drivers/ptp/ptp_vclock.c                   | 82 ++++++++++++++--------
 include/linux/netdevice.h                  | 21 ++++++
 include/linux/ptp_clock_kernel.h           | 38 ++++++++--
 include/linux/skbuff.h                     | 21 +++++-
 net/core/skbuff.c                          |  5 ++
 net/socket.c                               | 53 +++++++++++---
 12 files changed, 281 insertions(+), 62 deletions(-)

Comments

Jakub Kicinski May 4, 2022, 3:55 p.m. UTC | #1

On Sun,  1 May 2022 13:18:30 +0200 Gerhard Engleder wrote:
> 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 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 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
> like 2 step synchroisation 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 patches from Miroslav
> Lichvar.

The netdev parts looks sane, I think.

Richard? Let me also add Willem, Jonathan and Martin.

Richard Cochran May 5, 2022, 2:08 p.m. UTC | #2

On Wed, May 04, 2022 at 08:55:52AM -0700, Jakub Kicinski wrote:

> The netdev parts looks sane, I think.
> 
> Richard? Let me also add Willem, Jonathan and Martin.

Series is much improved... one more revision and I think it will be ready.

Thanks,
Richard