Re: [PATCH v2 6/7] net: dsa: b53: Add logic for TX timestamping

From: Richard Cochran <richardcochran@gmail.com>
To: Vladimir Oltean <olteanv@gmail.com>
Cc: Kurt Kanzenbach <kurt@linutronix.de>,
	Martin Kaistra <martin.kaistra@linutronix.de>,
	Florian Fainelli <f.fainelli@gmail.com>,
	Andrew Lunn <andrew@lunn.ch>,
	Vivien Didelot <vivien.didelot@gmail.com>,
	"David S. Miller" <davem@davemloft.net>,
	Jakub Kicinski <kuba@kernel.org>,
	John Stultz <john.stultz@linaro.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	Stephen Boyd <sboyd@kernel.org>,
	Russell King <linux@armlinux.org.uk>,
	Marc Kleine-Budde <mkl@pengutronix.de>,
	linux-kernel@vger.kernel.org, netdev@vger.kernel.org
Subject: Re: [PATCH v2 6/7] net: dsa: b53: Add logic for TX timestamping
Date: Wed, 10 Nov 2021 07:08:55 -0800	[thread overview]
Message-ID: <20211110150855.GD28458@hoboy.vegasvil.org> (raw)
In-Reply-To: <20211110130545.ga7ajracz2vvzotg@skbuf>

On Wed, Nov 10, 2021 at 03:05:45PM +0200, Vladimir Oltean wrote:

> So it is true that ptp4l is single threaded and always polls
> synchronously for the reception of a TX timestamp on the error queue
> before proceeding to do anything else. But writing a kernel driver to
> the specification of a single user space program is questionable.

There are a number of HW devices on the market that only support one
outstanding Tx time stamp.  The implementation of ptp4l follows this
limitation because a) it allows ptp4l to "just work" with most HW, and
b) there is as yet no practical advantage to asynchronous Tx time
stamping.

The premise of (b) might change if you had a GM serving hundreds or
thousands of unicast clients, for example.

In any case, I agree that the driver should enable the capabilities of
the HW and not impose artificial limitations.

Thanks,
Richard