> > 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. -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
