On 02/10/2020 21:01, Vinicius Costa Gomes wrote: > Hi Erez, > > Erez Geva <erez.geva....@siemens.com> writes: > >> Add support for using PTP clock with >> Traffic control Earliest TxTime First (ETF) Qdisc. >> >> Why do we need ETF to use PTP clock? >> Current ETF requires to synchronization the system clock >> to the PTP Hardware clock (PHC) we want to send through. >> But there are cases that we can not synchronize the system clock with >> the desire NIC PHC. >> 1. We use several NICs with several PTP domains that our device >> is not allowed to be PTP master. >> And we are not allowed to synchronize these PTP domains. >> 2. We are using another clock source which we need for our system. >> Yet our device is not allowed to be PTP master. >> Regardless of the exact topology, as the Linux tradition is to allow >> the user the freedom to choose, we propose a patch that will allow >> the user to configure the TC-ETF with a PTP clock as well as >> using the system clock. >> * NOTE: we do encourage the users to synchronize the system clock with >> a PTP clock. >> As the ETF watchdog uses the system clock. >> Synchronizing the system clock with a PTP clock will probably >> reduce the frequency different of the PHC and the system clock. >> As sequence, the user might be able to reduce the ETF delta time >> and the packets latency cross the network. >> >> Follow the decision to derive a dynamic clock ID from the file description >> of an opened PTP clock device file. >> We propose a simple way to use the dynamic clock ID with the ETF Qdisc. >> We will submit a patch to the "tc" tool from the iproute2 project >> once this patch is accepted. >> > > In addition to what Thomas said, I would like to add some thoughts > (mostly re-wording some of Thomas' comments :-)). > > I think that there's an underlying problem/limitation that is the cause > of the issue (or at least a step in the right direction) you are trying > to solve: the issue is that PTP clocks can't be used as hrtimers. > > I didn't spend a lot of time thinking about how to solve this (the only > thing that comes to mind is having a timecounter, or similar, "software > view" over the PHC clock). > > Anyway, my feeling is that until this is solved, we would only be > working around the problem, and creating even more hard to handle corner > cases. > > > Cheers, >
You are right. Thanks for the insight. Erez
