Hi Miroslav, On Thu, 2 Jun 2022 at 15:01, Miroslav Lichvar <[email protected]> wrote:
> 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); > This is not going to work. As the delay mechanism is per port configuration so cannot be applied at the clock level. TS_PROC is also a per port configuration. 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. > We would like to follow it as per spec as it is easy for everyone to understand the code and easily co-relate with the standards. Since E2E/P2P was named as DM_XXX, we were in perception that you had followed the standard while adding the enums. We are planning to add other remaining delay mechanisms as well. [image: image.png] Thanks, Devasish Dey SyncMonk Technologies
_______________________________________________ Linuxptp-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
