[PATCH net-next] net: mvneta: add support for hardware timestamps

[PATCH net-next] net: mvneta: add support for hardware timestamps

[Russell King]

Add support for hardware timestamps in (e.g.) the PHY by calling
skb_tx_timestamp() as close as reasonably possible to the point that
the hardware is instructed to send the queued packets.

Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
---
 drivers/net/ethernet/marvell/mvneta.c | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/drivers/net/ethernet/marvell/mvneta.c b/drivers/net/ethernet/marvell/mvneta.c
index 476e73e502fe..5f4e28085640 100644
--- a/drivers/net/ethernet/marvell/mvneta.c
+++ b/drivers/net/ethernet/marvell/mvneta.c
@@ -2985,6 +2985,13 @@ static netdev_tx_t mvneta_tx(struct sk_buff *skb, struct net_device *dev)
 		if (txq->count >= txq->tx_stop_threshold)
 			netif_tx_stop_queue(nq);
 
+		/* FIXME: This is not really the true transmit point, since
+		 * we batch up several before hitting the hardware, but is
+		 * the best we can do without more complexity to walk the
+		 * packets in the pending section of the transmit queue.
+		 */
+		skb_tx_timestamp(skb);
+
 		if (!netdev_xmit_more() || netif_xmit_stopped(nq) ||
 		    txq->pending + frags > MVNETA_TXQ_DEC_SENT_MASK)
 			mvneta_txq_pend_desc_add(pp, txq, frags);
-- 
2.47.3

Re: [PATCH net-next] net: mvneta: add support for hardware timestamps

[Russell King (Oracle)]

On Tue, Sep 09, 2025 at 04:30:01PM +0100, Russell King wrote:
> Add support for hardware timestamps in (e.g.) the PHY by calling
> skb_tx_timestamp() as close as reasonably possible to the point that
> the hardware is instructed to send the queued packets.
> 
> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
> ---
>  drivers/net/ethernet/marvell/mvneta.c | 7 +++++++
>  1 file changed, 7 insertions(+)
> 
> diff --git a/drivers/net/ethernet/marvell/mvneta.c b/drivers/net/ethernet/marvell/mvneta.c
> index 476e73e502fe..5f4e28085640 100644
> --- a/drivers/net/ethernet/marvell/mvneta.c
> +++ b/drivers/net/ethernet/marvell/mvneta.c
> @@ -2985,6 +2985,13 @@ static netdev_tx_t mvneta_tx(struct sk_buff *skb, struct net_device *dev)
>  		if (txq->count >= txq->tx_stop_threshold)
>  			netif_tx_stop_queue(nq);
>  
> +		/* FIXME: This is not really the true transmit point, since
> +		 * we batch up several before hitting the hardware, but is
> +		 * the best we can do without more complexity to walk the
> +		 * packets in the pending section of the transmit queue.
> +		 */
> +		skb_tx_timestamp(skb);
> +

A question to netdev timestamping people...

As I understand it, skb_tx_timestamp() not only adds support for
PHY-based hardware timestamping, but also adds software timestamping
at the point this call is made (hence why it needs to be placed
carefully.)

If a driver has skb_tx_timestmap() added, should the driver also
fill in the ethtool .get_ts_info() method, presumably with
ethtool_op_get_ts_info() ?

Thanks.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!

Re: [PATCH net-next] net: mvneta: add support for hardware timestamps

[Jakub Kicinski]

On Tue, 9 Sep 2025 17:17:45 +0100 Russell King (Oracle) wrote:
> If a driver has skb_tx_timestmap() added, should the driver also
> fill in the ethtool .get_ts_info() method, presumably with
> ethtool_op_get_ts_info() ?

Yes.

Re: [PATCH net-next] net: mvneta: add support for hardware timestamps

[Jakub Kicinski]

On Tue, 09 Sep 2025 16:30:01 +0100 Russell King wrote:
> +		/* FIXME: This is not really the true transmit point, since
> +		 * we batch up several before hitting the hardware, but is
> +		 * the best we can do without more complexity to walk the
> +		 * packets in the pending section of the transmit queue.
> +		 */

That's true for all SW/driver timestamps I know of. 
No objection to keeping the comment, just a FWIW.

Re: [PATCH net-next] net: mvneta: add support for hardware timestamps

[Russell King (Oracle)]

On Tue, Sep 09, 2025 at 02:01:13PM -0700, Jakub Kicinski wrote:
> On Tue, 09 Sep 2025 16:30:01 +0100 Russell King wrote:
> > +		/* FIXME: This is not really the true transmit point, since
> > +		 * we batch up several before hitting the hardware, but is
> > +		 * the best we can do without more complexity to walk the
> > +		 * packets in the pending section of the transmit queue.
> > +		 */
> 
> That's true for all SW/driver timestamps I know of. 
> No objection to keeping the comment, just a FWIW.

I'll drop the "FIXME:" prefix and re-send tomorrow with the
.get_ts_info() op filled in.

Thanks Jakub.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!