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. _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
