On Wed, Jan 27, 2016 at 6:06 PM, Jesse Gross <je...@kernel.org> wrote: > 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. > I agree and thats why I wanted to implement better timer based on rdtsc which is not dependent on specific CPU scheduling.
> 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/ There are different analysis regarding clock_gettime() results. So I performed test to check the performance of clock_gettime() API and RDTSC. RDTSC takes around 35% of the time compared to clock_gettime(). So clock_gettime() is not bad to start with. Once we start to saturate 10G link with DPDK tunnel packet this could be a issue. We can explore options that time. Thanks. _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
