Re: [PATCH for-next 09/10] IB/mlx4: Add timestamp_mask and hca_core_clock to query_device

Christoph Lameter
2015-06-01T11:44:50Z

> > This is sufficient since it can be converted to ns or whatever one wants.
>
> It is sufficient for your use. It is not, however, a good API.

I hate these foggy statements that you guys come up with. Why is it not a
good API? Having a cycle counter without processiing overhead is a good
thing and the way counters are handled is pretty well established.

> > The API provides the abilty to retrieve the clock freq which is
> > sufficient for the user to convert the value to meaningful time values.
>
> I would prefer if the access to the timestamp were implemented via a
> function in libibverbs (I haven't looked at the git repo, too little
> time, I'll get to it). Something like ibv_get_cqe_timestamp(). That
> function should be general and return a suitable, normalized value (ns
> probably). If you just want a simple comparator without the overhead of
> normalizing to time, and are willing to accept the consequences of that,
> then I would expect you to use something like

That would introduce additional latencies and would make that feature no
longer useful to us. The advantage of this approach is that the counter is
in the same cacheline that is already used. It is very low overhead.

> ibv_get_raw_cqe_timestamp() to get the unadulterated cycle counter. For
> the most part, the user space application should not know details like
> "we are using a cycle counter in the HCA processor for timestamping",

Why not? A cycle counter is the general way of providing
timestamps in hardware. RDTSC is such a cycle counter as well. There are
numerous examples of counters like that.