Re: [PATCH net-next 0/5] PTP support for the SJA1105 DSA driver

[Vladimir Oltean <olteanv@gmail.com>]

On 5/29/19 7:52 AM, Richard Cochran wrote:
> On Wed, May 29, 2019 at 02:56:22AM +0300, Vladimir Oltean wrote:
>> Not all is rosy, though.
> 
> You can sure say that again!
>   
>> PTP timestamping will only work when the ports are bridged. Otherwise,
>> the metadata follow-up frames holding RX timestamps won't be received
>> because they will be blocked by the master port's MAC filter. Linuxptp
>> tries to put the net device in ALLMULTI/PROMISC mode,
> 
> Untrue.
> 

I'm sorry, then what does this code from raw.c do?

> 	mreq.mr_ifindex = index;
> 	mreq.mr_type = PACKET_MR_ALLMULTI;
> 	mreq.mr_alen = 0;
> 	if (!setsockopt(fd, SOL_PACKET, option, &mreq, sizeof(mreq))) {
> 		return 0;
> 	}
> 	pr_warning("setsockopt PACKET_MR_ALLMULTI failed: %m");
> 
> 	mreq.mr_ifindex = index;
> 	mreq.mr_type = PACKET_MR_PROMISC;
> 	mreq.mr_alen = 0;
> 	if (!setsockopt(fd, SOL_PACKET, option, &mreq, sizeof(mreq))) {
> 		return 0;
> 	}
> 	pr_warning("setsockopt PACKET_MR_PROMISC failed: %m");


>> but DSA doesn't
>> pass this on to the master port, which does the actual reception.
>> The master port is put in promiscous mode when the slave ports are
>> enslaved to a bridge.
>>
>> Also, even with software-corrected timestamps, one can observe a
>> negative path delay reported by linuxptp:
>>
>> ptp4l[55.600]: master offset          8 s2 freq  +83677 path delay     -2390
>> ptp4l[56.600]: master offset         17 s2 freq  +83688 path delay     -2391
>> ptp4l[57.601]: master offset          6 s2 freq  +83682 path delay     -2391
>> ptp4l[58.601]: master offset         -1 s2 freq  +83677 path delay     -2391
>>
>> Without investigating too deeply, this appears to be introduced by the
>> correction applied by linuxptp to t4 (t4c: corrected master rxtstamp)
>> during the path delay estimation process (removing the correction makes
>> the path delay positive).
> 
> No.  The root cause is the time stamps delivered by the hardware or
> your driver.  That needs to be addressed before going forward.
> 

How can I check that the timestamps are valid?

Regards,
-Vladimir

> Thanks,
> Richard
>