Hi > -----Original Message----- > From: Richard Cochran [mailto:richardcoch...@gmail.com] > Sent: Tuesday, April 12, 2016 12:39 AM > To: Keller, Jacob E <jacob.e.kel...@intel.com> > Cc: linuxptp-devel@lists.sourceforge.net > Subject: Re: [Linuxptp-devel] ptp4l, multicast, and clearing Rx timestamp > settings > > Jake, > > On Mon, Apr 11, 2016 at 09:19:28PM +0000, Keller, Jacob E wrote: > > 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... > > > 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. > > > 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. > That makes sense. > 2. When stopping ptp4l, use hwstamp_ctl to reset the configuration as > you see fit. > > > 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 ------------------------------------------------------------------------------ Find and fix application performance issues faster with Applications Manager Applications Manager provides deep performance insights into multiple tiers of your business applications. It resolves application problems quickly and reduces your MTTR. Get your free trial! https://ad.doubleclick.net/ddm/clk/302982198;130105516;z _______________________________________________ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
