On Thu, Jan 28, 2016 at 2:23 PM, Jesse Gross <je...@kernel.org> wrote: > On Thu, Jan 28, 2016 at 2:10 PM, pravin shelar <pshe...@ovn.org> wrote: >> 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: >>> 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 for testing, that sounds like a good plan. One other thing is > that at least with STT, we only invoke this function when doing > reassembly. That means we're likely dealing with MTU sized packets and > the packet rate isn't too high.
Good point. _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev