On Thu, Jun 02, 2022 at 12:33:21PM +0530, Devasish Dey wrote:
> NO_DELAY mechanism address when user or system does not have any delay
> measurement mechanism. The Newly introduced options for ts_proc gives users
> clear indication that delay measurement mechanism is not going to be used
> in this mode of operation.
Even if we ignore the technical aspect of the implementation, I think
it would not be very user friendly to have to set two different
options to get it working.
> Currently we do not see any available option to work with no_delay
> mechanism. If we need to use the same option as suggested we need to update
> the existing behavior.
You could change the behavior of the initial_delay option to accept
zero as a valid value, but that would break compatibility with
existing configuration files that set it to 0 for "no value".
I'd suggest to call tsproc_set_delay() in handle_state_decision_event(),
which already does that for the initial_delay option. The condition
could be extended like this:
if (!tmv_is_zero(c->initial_delay) || best_dm == DM_NO_MECHANISM)
tsproc_set_delay(c->tsproc, c->initial_delay);
or maybe there could be a separate call further down in handling of
the PS_SLAVE case. You would need to add a new port function to get
its delay mechanism.
Also, I'd suggest to rename the DM constant and user setting to
DM_NONE and "none" to make it shorter and less ugly. I don't think we
need to follow the spec here literally.
--
Miroslav Lichvar
_______________________________________________
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
