[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <b9397ec109ca1055af74bd8f20be8f64a7a1c961.camel@oss.nxp.com>
Date: Mon, 27 Sep 2021 18:00:08 +0200
From: Sebastien Laveze <sebastien.laveze@....nxp.com>
To: Richard Cochran <richardcochran@...il.com>
Cc: netdev@...r.kernel.org, linux-kernel@...r.kernel.org,
yangbo.lu@....com, yannick.vignon@....nxp.com,
rui.sousa@....nxp.com
Subject: Re: [PATCH net-next] ptp: add vclock timestamp conversion IOCTL
On Mon, 2021-09-27 at 07:59 -0700, Richard Cochran wrote:
> I'm not wild about having yet another ioctl for functionality that
> already exists.
I was expecting some pushback :)
> > This binding works well if the application requires all timestamps in the
> > same domain but is not convenient when multiple domains need to be
> > supported using a single socket.
>
> Opening multiple sockets is not rocket science.
I agree but you end-up handling or filtering the same traffic for each
socket. Not rocket science, but not "ideal".
> > Typically, IEEE 802.1AS-2020 can be implemented using a single socket,
> > the CMLDS layer using raw PHC timestamps and the domain specific
> > timestamps converted in the appropriate gPTP domain using this IOCTL.
>
> You say "typically", but how many applications actually do this? I
> can't think of any at all.
The "typically" was more a reference to this possible implementation of
AS-2020 using a common CMLDS layer and several domains using a single
socket.
So, without this IOCTL the design would be 1 socket for CMLDS layer
and 1 socket for each domain plus some specific filtering for each
socket to avoid processing the unwanted traffic.
With this IOCTL, the design would be 1 socket and 1 conversion for the
sync messages in the appropriate domain.
This also brings a finer granularity for per-domain timestamps which
may be useful for other applications.
>
> Thanks,
> Richard
Thanks,
Seb
Powered by blists - more mailing lists