lkml.org 
[lkml]   [2019]   [May]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH net-next 0/5] PTP support for the SJA1105 DSA driver
From
Date
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
>

\
 
 \ /
  Last update: 2019-05-29 22:42    [from the cache]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and my Meterkast|Read the blog