[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20210704133331.GA4268@hoboy.vegasvil.org>
Date: Sun, 4 Jul 2021 06:33:31 -0700
From: Richard Cochran <richardcochran@...il.com>
To: Yangbo Lu <yangbo.lu@....com>
Cc: netdev@...r.kernel.org, linux-kernel@...r.kernel.org,
linux-kselftest@...r.kernel.org, mptcp@...ts.linux.dev,
"David S . Miller" <davem@...emloft.net>,
Jakub Kicinski <kuba@...nel.org>,
Mat Martineau <mathew.j.martineau@...ux.intel.com>,
Matthieu Baerts <matthieu.baerts@...sares.net>,
Shuah Khan <shuah@...nel.org>,
Michal Kubecek <mkubecek@...e.cz>,
Florian Fainelli <f.fainelli@...il.com>,
Andrew Lunn <andrew@...n.ch>, Rui Sousa <rui.sousa@....com>,
Sebastien Laveze <sebastien.laveze@....com>
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:
> 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?
Thanks,
Richard
Powered by blists - more mailing lists