lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Wed, 21 Mar 2012 13:02:38 -0400 From: chetan loke <loke.chetan@...il.com> To: Richard Cochran <richardcochran@...il.com> Cc: netdev@...r.kernel.org, e1000-devel@...ts.sourceforge.net, jacob.e.keller@...el.com, jeffrey.t.kirsher@...el.com, john.ronciak@...el.com, john.stultz@...aro.org, tglx@...utronix.de Subject: Re: [PATCH net V4 2/2] igb: offer a PTP Hardware Clock instead of the timecompare method On Wed, Mar 21, 2012 at 12:08 PM, Richard Cochran <richardcochran@...il.com> wrote: > On Wed, Mar 21, 2012 at 11:00:59AM -0400, chetan loke wrote: >> >> Once PHC->gettime goes live(aka exported to user space), we can't >> really control how users will use it in their applications. There >> could be 100+ apps all trying to get real-time from the network to do >> some time-keeping stuff. They might pound the ioctls at high rate. The >> last thing we would want is to self-induce a light weight DOS. > > Well, if people want to write programs that make no sense at all, > then I can cannot stop them. There really isn't any point in general > applications using the PHC directly. You can easily synchronize the I thought the core patches enables using PHC as a reference time, no? So that seems to be contradicting the PHC API. If there's no point then why are we exporting PHC->get_time as a generic interface? May be just limit get_time interface to something like ethtool? > system time to the PHC to within a few microseconds. Just the error > from reading the clock (due to various kinds of latency) is much > larger than that. > Once, the clocks are in-sync, it's not an error - but *somewhat fixed* latency. There are users who don't want to spend extra money for expensive GPS time-sync stuff but yet have enough CPUs such that they can dedicate 1 CPU for book-keeping. For such users, this *somewhat fixed* latency should be constant over a period of time even when other CPUs are processing traffic at line rate. > Also, although you might be able to optimize clock_gettime performance > for a PCI card, this will never work for PHY based devices, which, by > the way, offer superior PTP time stamping. So, in general, applications > should stick to reading the system time. We still need to get some more tools out there in order to support the > PHC->system synchronization, but that is not too far off. That is what > I am working on now, Sounds good on the tools part. But if applications should stick to reading sys-time then either we shouldn't export the API or export it selectively.If there's an API then user-space guys will use it. For this discussion, lets focus on PCI cards because that is what this patch talks about. Also the majority of the deployment will be LOM or PCI cards. > > Thanks, > Richard > thanks Chetan -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists