On Wed, Jan 27, 2016 at 4:36 PM, pravin shelar <pshe...@ovn.org> wrote: > On Mon, Jan 25, 2016 at 9:34 AM, Jesse Gross <je...@kernel.org> wrote: >> I'm also not sure that it is really safe to use the raw TSC in all >> cases. It's possible that DPDK support is compiled in but we aren't >> using a DPDK port - in that case threads might not be pinned to a >> particular core (even in the DPDK case we might want to allow the >> threads to float in some situations). > > This function is only used in userspace datapath. So even if DPDK is > compiled in it should not matter much unless userspace datapath is > configured. > AFAIK local timestamp is most efficient way to generate timestamp. So > handle scheduling issues, I will add cpu information along with the > timestamp to implement better timer.
It's true that it's only used by the userspace datapath but that doesn't necessarily mean that it's using DPDK - FreeBSD uses the userspace datapath, not to mention the unit tests. As a result, I think that we should make sure that the behavior is correct in non-DPDK cases. Direct use of the TSC has a lot of nasty cases which vary depending on the CPU that you are on, such as being affected by power management on older CPUs. My guess is that they will mostly not affect DPDK since that requires relatively new CPUs but it's certainly something to be careful of. I'm actually not sure that the performance difference is all that significant between TSC and clock_gettime() in the case of STT. On modern versions of Linux clock_gettime() is a VDSO that is driven by the TSC. When you consider all of the other machinations that STT does, it seems that the difference could easily be lost in the noise. Here are some benchmarks: https://btorpey.github.io/blog/2014/02/18/clock-sources-in-linux/ _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
