[dpdk-dev] [PATCH v2] net/pcap: support software Tx nanosecond timestamps

Ferruh Yigit ferruh.yigit at intel.com
Wed Jun 10 14:17:14 CEST 2020


On 6/9/2020 8:57 PM, Vivien Didelot wrote:
> Hi Stephen,
> 
> On Tue, 9 Jun 2020 12:43:57 -0700, Stephen Hemminger <stephen at networkplumber.org> wrote:
>> On Tue,  9 Jun 2020 15:07:19 -0400
>> Vivien Didelot <vivien.didelot at gmail.com> wrote:
>>
>>>  
>>> +#define NSEC_PER_SEC	1000000000L
>>> +
>>>  static inline void
>>>  calculate_timestamp(struct timeval *ts) {
>>>  	uint64_t cycles;
>>> @@ -294,8 +296,14 @@ calculate_timestamp(struct timeval *ts) {
>>>  
>>>  	cycles = rte_get_timer_cycles() - start_cycles;
>>>  	cur_time.tv_sec = cycles / hz;
>>> -	cur_time.tv_usec = (cycles % hz) * 1e6 / hz;
>>> -	timeradd(&start_time, &cur_time, ts);
>>> +	cur_time.tv_usec = (cycles % hz) * NSEC_PER_SEC / hz;
>>> +
>>> +	ts->tv_sec = start_time.tv_sec + cur_time.tv_sec;
>>> +	ts->tv_usec = start_time.tv_usec + cur_time.tv_usec;
>>> +	if (ts->tv_usec >= NSEC_PER_SEC) {
>>> +		ts->tv_usec -= NSEC_PER_SEC;
>>> +		ts->tv_sec += 1;
>>> +	}
>>>  }
>>>  
>>
>> You may want to pre-compute the reciprocal here to save the expensive
>> cost of divide in the fast path. See rte_reciprocal.
> 
> Please note that I did not change the calculation logic that was previously
> used here. Thus pre-computing the reciprocal here to save the expensive cost
> of divide in the fast path seems out of the scope of this patch to me.
> 
> Can we keep this for a future patch maybe?
> 

+1 to have this as incremental improvement to this patch.


More information about the dev mailing list