[Linuxptp-devel] ptp4l, multicast, and clearing Rx timestamp settings

[Keller, Jacob E]

Hi,

I am experiencing an interesting issue on some devices. I know the
following scenario is not really a real world setup but it will help
outline the issue and whether we ought to make a change to LinuxPTP.

Say you have 3 netdevices capable of performing hardware timestamping
connected to a switch.

You run ptp4l on the first two devices and begin syncing.

Then you start ptp4l on the 3rd device, and begin syncing. After a
while you kill ptp4l on the 3rd device, but leave the first two
syncing.

The result in my case is that the 3rd device's driver complains about
latched Rx timestamp registers and times out. This occurs, I believe,
because the hardware performs the Rx timestamp and puts it into RX
timestamp registers before deciding if it should drop the multicast
frame (as the multicast subscription should be cleared when the socket
goes away, if I understand correctly).

Thus, since the launch of ptp4l enabled Rx timestamp settings, the
hardware will now continuously trigger rx timestamp hang logic in the
driver until the PTP traffic on the other two ports is stopped.

My question for this list: Should ptp4l be updated to include a signal
handler to trap the exit signal(s) and reset the timestamp logic upon
exit? Or is there a better way this could be updated/handled in the
kernel? or is this not really an issue, and my driver should be fixed?

I don't know if it is really possible to fix my driver, since currently
it doesn't know when Rx timestamps have been disabled.

Regards,
Jake

[Richard Cochran]

Jake,

Post by Keller, Jacob E
My question for this list: Should ptp4l be updated to include a signal
handler to trap the exit signal(s) and reset the timestamp logic upon
exit?

No, I don't think so...

Post by Keller, Jacob E
Or is there a better way this could be updated/handled in the
kernel?

This is an unfortunate aspect of how the kernel handles HW time
stamping. As you know, this is enabled at the driver level, and so
the configuration is global, and it applies to every program that
would want to have time stamping.

Now, imagine you have HW that can time stamp every packet (like most
of the latest cards). You start ptp4l and some other program whose
purpose is network performance monitoring (for example). After a
while, you stop ptp4l. If ptp4l were to turn off time stamping at the
driver level, then the other program would suddenly stop working. Not
very polite, if you ask me.

Really, the driver level configuration is a global option for the
entire system. In an ideal world, the sysadmin would set the policy
once for all programs. However, as a practical matter, we turn on
SIOCSHWTSTAMP in sk.c:hwts_init() just to make it easier to deploy the
program. And we do not turn it off again on exit, on purpose, for the
above mentioned reason.

Post by Keller, Jacob E
or is this not really an issue, and my driver should be fixed?

I don't see it as a big issue. You have two workarounds:

1. Have the driver do WARN_ONCE or rate limit the printk, in order to
avoid spamming the kernel log.

2. When stopping ptp4l, use hwstamp_ctl to reset the configuration as
you see fit.

Post by Keller, Jacob E
I don't know if it is really possible to fix my driver, since currently
it doesn't know when Rx timestamps have been disabled.

You mean at the socket level, right?

Thanks,
Richard

[Keller, Jacob E]

Hi

-----Original Message-----
Sent: Tuesday, April 12, 2016 12:39 AM
Subject: Re: [Linuxptp-devel] ptp4l, multicast, and clearing Rx timestamp
settings
Jake,

Post by Keller, Jacob E
My question for this list: Should ptp4l be updated to include a signal
handler to trap the exit signal(s) and reset the timestamp logic upon
exit?

No, I don't think so...

Post by Keller, Jacob E
Or is there a better way this could be updated/handled in the
kernel?

This is an unfortunate aspect of how the kernel handles HW time
stamping. As you know, this is enabled at the driver level, and so
the configuration is global, and it applies to every program that
would want to have time stamping.
Now, imagine you have HW that can time stamp every packet (like most
of the latest cards). You start ptp4l and some other program whose
purpose is network performance monitoring (for example). After a
while, you stop ptp4l. If ptp4l were to turn off time stamping at the
driver level, then the other program would suddenly stop working. Not
very polite, if you ask me.

Right that's what I was thinking.

Really, the driver level configuration is a global option for the
entire system. In an ideal world, the sysadmin would set the policy
once for all programs. However, as a practical matter, we turn on
SIOCSHWTSTAMP in sk.c:hwts_init() just to make it easier to deploy the
program. And we do not turn it off again on exit, on purpose, for the
above mentioned reason.

Post by Keller, Jacob E
or is this not really an issue, and my driver should be fixed?

1. Have the driver do WARN_ONCE or rate limit the printk, in order to
avoid spamming the kernel log.

That makes sense.

2. When stopping ptp4l, use hwstamp_ctl to reset the configuration as
you see fit.

Post by Keller, Jacob E
I don't know if it is really possible to fix my driver, since currently
it doesn't know when Rx timestamps have been disabled.

You mean at the socket level, right?

I meant that there is no way for it to tell that all running software no longer cares about timestamps, which I guess would mean all sockets which cared have stopped?

Thanks,
Jake