>> PTP traffic by its nature is very low. >> I do not see any benefit for a filter that supports only client or only >> master PTP traffic.
>That argument does not hold up in the datacenter. Once you scale up to >100000 nodes @128pps trying to synchronize to a GM it's no longer what > I'd consider "very low". Furthermore, considering a TSN context where a low cycle time, for instance 0.5ms, and a lower sync interval of -5(e.g., logSyncInterval=-5) is needed then the PTP traffic is no longer "very low". hence it worth the trouble. If the tx poll time(out) is also considered then it makes sense to reduce this overhead for the critical real time application. Best regards Bilal ________________________________ From: Maciek Machnikowski <mac...@machnikowski.net> Sent: 28 November 2023 18:25 To: linuxptp-devel@lists.sourceforge.net <linuxptp-devel@lists.sourceforge.net> Subject: Re: [Linuxptp-devel] [PATCH v2] Add support for DELAY_REQ and SYNC packets RX filters On 28/11/2023 14:39, Erez wrote: > > > On Tue, 28 Nov 2023 at 12:55, Miroslav Lichvar <mlich...@redhat.com > <mailto:mlich...@redhat.com>> wrote: > > On Sun, Nov 26, 2023 at 11:10:05AM -0800, Richard Cochran wrote: > > The Rx filters are applied globally at the device level, but the PTP > > operates at the application level. This means that the Rx filter are > > shared between applications. And so you can see that one application > > cannot simply change the shared global settings at run time. > > This problem already exists, e.g. with ptpv2-l4-event vs ptpv2-l2-event. > We could say that all hardware that cannot timestamp all packets is > broken, but it's so common that it has to be supported. If the > hardware which cannot timestamp all event messages is very rare, ok, > maybe it's not worth the trouble. > > However, timestamping only sync messages has an advantage with very > large number of clients as they don't have timestamp each other's > delay requets and timestamping of sync messages is more reliable. > > > PTP traffic by its nature is very low. > I do not see any benefit for a filter that supports only client or only > master PTP traffic. That argument does not hold up in the datacenter. Once you scale up to 100000 nodes @128pps trying to synchronize to a GM it's no longer what I'd consider "very low". Thanks, Maciek > > Perhaps the kernel should add a HWTSTAMP_FILTER_PTP_V2_ALL_EVENT, > that supports multiple PTP services on several layers. > > Erez > > > -- > Miroslav Lichvar > > > > _______________________________________________ > Linuxptp-devel mailing list > Linuxptp-devel@lists.sourceforge.net > <mailto:Linuxptp-devel@lists.sourceforge.net> > https://lists.sourceforge.net/lists/listinfo/linuxptp-devel > <https://lists.sourceforge.net/lists/listinfo/linuxptp-devel> > > > > _______________________________________________ > Linuxptp-devel mailing list > Linuxptp-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/linuxptp-devel _______________________________________________ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
_______________________________________________ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
