Re: [PATCH net-next v1 4/4] net: lan966x: generate software timestamp just before the doorbell

Hi Horatiu,

On Thu, May 8, 2025 at 3:08 PM Horatiu Vultur
[off-list ref] wrote:

The 05/08/2025 11:33, Jason Xing wrote:

quoted

From: Jason Xing <kernelxing@tencent.com>

Make sure the call of skb_tx_timestamp as close to the doorbell.

Signed-off-by: Jason Xing <kernelxing@tencent.com>
---
 drivers/net/ethernet/microchip/lan966x/lan966x_fdma.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/microchip/lan966x/lan966x_fdma.c b/drivers/net/ethernet/microchip/lan966x/lan966x_fdma.c
index 502670718104..e030f23e5145 100644
--- a/drivers/net/ethernet/microchip/lan966x/lan966x_fdma.c
+++ b/drivers/net/ethernet/microchip/lan966x/lan966x_fdma.c

@@ -730,7 +730,6 @@ int lan966x_fdma_xmit(struct sk_buff *skb, __be32 *ifh, struct net_device *dev)
                }
        }

-       skb_tx_timestamp(skb);

Changing this will break the PHY timestamping because the frame gets
modified in the next line, meaning that the classify function will
always return PTP_CLASS_NONE.

Sorry that I'm not that familiar with the details. I will remove it
from this series, but still trying to figure out what cases could be.

Do you mean it can break when bpf prog is loaded because
'skb_push(skb, IFH_LEN_BYTES);' expands the skb->data area?  May I ask
how the modified data of skb breaks the PHY timestamping feature?

Thanks,
Jason

Nacked-by: Horatiu Vultur [off-list ref]

quoted

        skb_push(skb, IFH_LEN_BYTES);
        memcpy(skb->data, ifh, IFH_LEN_BYTES);
        skb_put(skb, 4);

@@ -768,6 +767,7 @@ int lan966x_fdma_xmit(struct sk_buff *skb, __be32 *ifh, struct net_device *dev)
                next_dcb_buf->ptp = true;

        /* Start the transmission */
+       skb_tx_timestamp(skb);
        lan966x_fdma_tx_start(tx);

        return NETDEV_TX_OK;
--

2.43.5

--
/Horatiu