Performance is not the main concern here, but cycle count measurement accuracy. 
E.g. Intel rdtsc cycle counter read latency is few cycles where as 
clock_gettime() seems to take over a thousand. System call latencies also vary 
since those may launch other kernel services, which adds jitter to cycle count 
measurements.

Could we organize arch specific stuff better (no #ifdefs, but configure/build 
mechanism) and continue to support e.g. rdtsc.

-Petri


From: [email protected] 
[mailto:[email protected]] On Behalf Of ext Bill Fischofer
Sent: Friday, March 06, 2015 6:42 PM
To: Mike Holmes
Cc: lng-odp
Subject: Re: [lng-odp] [PATCH] linux-generic: time: remove platform specific 
acceleration

I agree with Mike.  Now that we have an official LNG performance 
implementation, linux-generic should focus on being a simple and clean 
functional implementation that elaborates the intended behavior of the ODP APIs 
without being overly concerned with performance.  That doesn't mean we don't do 
straightforward functional optimizations that are algorithmic in nature, just 
that there shouldn't be any platform-specific tuning paths in linux-generic.

On Fri, Mar 6, 2015 at 10:35 AM, Mike Holmes 
<[email protected]<mailto:[email protected]>> wrote:
The DPDK implementation will take the X86 optimizations, presumably Cavium 
already have Octeon acceleration in their own ODP implementation.

The linux generic implementation should be a model for the behavior of ODP, it 
happens to run in Linux but that should not be confused with it being used in 
any real application.

If we fill it with optimizations it will be harder to maintain as a pure model.

Mike

On 6 March 2015 at 11:26, Maxim Uvarov 
<[email protected]<mailto:[email protected]>> wrote:
Where should be that implementations placed if we want other platform to reuse 
them?

Maxim.


On 03/06/15 19:22, Mike Holmes wrote:
Linux-generic should be a reference implementation and does not need
archetecture specific acceleration.

Signed-off-by: Mike Holmes 
<[email protected]<mailto:[email protected]>>
---
  platform/linux-generic/odp_time.c | 47 +++------------------------------------
  1 file changed, 3 insertions(+), 44 deletions(-)

diff --git a/platform/linux-generic/odp_time.c 
b/platform/linux-generic/odp_time.c
index 31d6656..6f40361 100644
--- a/platform/linux-generic/odp_time.c
+++ b/platform/linux-generic/odp_time.c
@@ -6,52 +6,13 @@
    #define _POSIX_C_SOURCE 200809L
  +#include <time.h>
  #include <odp/time.h>
-#include <odp/hints.h>
  #include <odp/system_info.h>
-
-#define GIGA 1000000000
-
-#if defined __x86_64__ || defined __i386__
-
-uint64_t odp_time_cycles(void)
-{
-       union {
-               uint64_t tsc_64;
-               struct {
-                       uint32_t lo_32;
-                       uint32_t hi_32;
-               };
-       } tsc;
-
-       __asm__ __volatile__ ("rdtsc" :
-                    "=a" (tsc.lo_32),
-                    "=d" (tsc.hi_32) : : "memory");
-
-       return tsc.tsc_64;
-}
-
-
-#elif defined __OCTEON__
-
-uint64_t odp_time_cycles(void)
-{
-       #define CVMX_TMP_STR(x) CVMX_TMP_STR2(x)
-       #define CVMX_TMP_STR2(x) #x
-       uint64_t cycle;
-
-       __asm__ __volatile__ ("rdhwr %[rt],$" CVMX_TMP_STR(31) :
-                          [rt] "=d" (cycle) : : "memory");
-
-       return cycle;
-}
-
-#else
-
-#include <time.h>
-#include <stdlib.h>
  #include <odp_debug_internal.h>
  +#define GIGA 1000000000
+
  uint64_t odp_time_cycles(void)
  {
        struct timespec time;
@@ -74,8 +35,6 @@ uint64_t odp_time_cycles(void)
        return cycles;
  }
  -#endif
-
  uint64_t odp_time_diff_cycles(uint64_t t1, uint64_t t2)
  {
        if (odp_likely(t2 > t1))

_______________________________________________
lng-odp mailing list
[email protected]<mailto:[email protected]>
http://lists.linaro.org/mailman/listinfo/lng-odp



--
Mike Holmes
Technical Manager - Linaro Networking Group
Linaro.org<http://www.linaro.org/> │ Open source software for ARM SoCs


_______________________________________________
lng-odp mailing list
[email protected]<mailto:[email protected]>
http://lists.linaro.org/mailman/listinfo/lng-odp

_______________________________________________
lng-odp mailing list
[email protected]
http://lists.linaro.org/mailman/listinfo/lng-odp

Reply via email to