[ovs-dev] [PATCH 3/8] timeval: Factor out cycles_counter().

[pravin shelar]

On Thu, Jan 28, 2016 at 2:23 PM, Jesse Gross <jesse at kernel.org> wrote:
> On Thu, Jan 28, 2016 at 2:10 PM, pravin shelar <pshelar at ovn.org> wrote:
>> On Wed, Jan 27, 2016 at 6:06 PM, Jesse Gross <jesse at kernel.org> wrote:
>>> On Wed, Jan 27, 2016 at 4:36 PM, pravin shelar <pshelar at ovn.org> wrote:
>>>> On Mon, Jan 25, 2016 at 9:34 AM, Jesse Gross <jesse at 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.