On Thu, Nov 30, 2023 at 04:52:44PM -0800, Kishen Maloor wrote: > > + p->cmlds_pmc = pmc_create(cfg, TRANS_UDS, > > + config_get_string(cfg, p->name, > > "cmlds_client_address"), > > + config_get_string(cfg, p->name, > > "cmlds_server_address"), > > + hops, > > + config_get_int(cfg, NULL, "domainNumber"), > > + config_get_int(cfg, p->name, > > "transportSpecific") << 4, > > I haven't studied the flow here, but using the P2P_COMMON instance's > transportSpecific and domainNumber above might cause the CMLDS server's > port_ignore() to drop this message as the > CMLDS ptp4l process would be configured with > transportSpecific/domain=0x2/0. > > Perhaps just passing 0x2/0 above will fix things? This is assuming that > there are no transportSpecific/domainNumber checks on the receive path > for CMLDS events (which seemed to be the case looking at the code).
Right, those two fields must match. So I think: - we'll need options for those two, and - this is another reason to use a separate pmc instance for cmlds rather than reusing the uds port. > > Right, so the next TODO is to enable FD_DELAY_TIMER for P2P_COMMON > > mode and let it 1) renew the push subscription and 2) catch the case > > when the push notification does not arrive on time. > > > > Yes, in our series CMLDS queries were performed synchronously at the Pdelay > request cadence. If serviceMeasurementValid=false then port->pdr_missing was > incremented and immediately followed by a call to port_capable(). This was > necessary as I recollect there was a related Avnu test case. > > If serviceMeasurementValid=true, then we set both peer_portid_valid and > p->nrate.ratio_valid to true so that port_capable() could evaluate to true. I think that logic can be implemented without any service Measurement Valid field in the TLV. Thanks, Richard _______________________________________________ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
