RE: [net-next, v5, 08/11] net: sock: extend SO_TIMESTAMPING for PHC binding
From: "Y.b. Lu" <yangbo.lu@nxp.com>
Date: 2021-07-05 08:19:36
Also in:
linux-kselftest, lkml, mptcp
Hi Richard,
-----Original Message----- From: Richard Cochran <richardcochran@gmail.com> Sent: 2021年7月4日 21:34 To: Y.b. Lu <yangbo.lu@nxp.com> Cc: netdev@vger.kernel.org; linux-kernel@vger.kernel.org; linux-kselftest@vger.kernel.org; mptcp@lists.linux.dev; David S . Miller [off-list ref]; Jakub Kicinski [off-list ref]; Mat Martineau [off-list ref]; Matthieu Baerts [off-list ref]; Shuah Khan [off-list ref]; Michal Kubecek [off-list ref]; Florian Fainelli [off-list ref]; Andrew Lunn [off-list ref]; Rui Sousa [off-list ref]; Sebastien Laveze [off-list ref] Subject: Re: [net-next, v5, 08/11] net: sock: extend SO_TIMESTAMPING for PHC binding On Wed, Jun 30, 2021 at 04:11:59PM +0800, Yangbo Lu wrote:quoted
Since PTP virtual clock support is added, there can be several PTP virtual clocks based on one PTP physical clock for timestamping. This patch is to extend SO_TIMESTAMPING API to support PHC (PTP Hardware Clock) binding by adding a new flag SOF_TIMESTAMPING_BIND_PHC. When PTP virtual clocks are in use, user space can configure to bind one for timestamping, but PTP physical clock is not supported and not needed to bind.Would it not be better to simply bind automatically? Like this pseudo code: if (hw_timestamping_requested() && interface_is_vclock()) { bind_vclock(); } It would be great to avoid forcing user space to use a new option. Especially because NOT setting the option makes no sense. Or maybe there is a use case for omitting the option? Thoughts?
When several ptp virtual clocks are created, the ptp physical clock is guaranteed for free running. What I think is, for timestamping, if no flag SOF_TIMESTAMPING_BIND_PHC, the timestamping keeps using ptp physical clock. If application wants to bind one ptp virtual clock for timestamping, the flag SOF_TIMESTAMPING_BIND_PHC should be set and clock index should be provided. After all, several ptp virtual clocks created are likely for different timescale/use case. There should be a method for any of applications to select the right one to use. Does it make sense? Thank you.
Thanks, Richard