> > I feel like I'm missing something. Again. > > I thought the reasonable rate of rate-adjustment is once a second, > > which doesn't make it 'hot' in any way. > > In which scenario would we frequently encounter this configuration? > > The Sync message rate is not 1 per second, but rather the interval is > specified by the PTP profile as 2^N seconds, -128 <= N < 128. > > This is called the logSyncInterval, and in the Telecom profile [1] for > example, N = -4.
While it surely answers my question, I still don't think of an event reoccurring 16 times a second as optimization-crucial. Is there any reasonable scenario where the interval is significantly smaller, or is it merely some theoretical specification? [I'd like to see the machine that can handle the 2^(-128) sec interval] > Anyhow, as far the original question goes, maybe you could have the > specific HW driver pass its adjfreq function pointer into the generic > driver and let the generic driver copy it directly into the > ptp_clock_info. Again, I don't see how we can achieve that given that qede has to check Its internal state to check whether it's right to utilize the ptp-related hw configurations and only then call the qed function. As qed can't do it for qede, we can't directly map qed's function into the ptp_clock_info, but rather have to call it after taking qede's state-lock.
