On Thu, 28 May 2015, Jason Gunthorpe wrote: > > This is sufficient since it can be converted to ns or whatever one wants. > > Sure it is sufficient, but is it a robust UAPI, will it support > multiple hardware vendors?
What would prevent other hardware vendors from exporting their counters? > Is anyone else in ethernet using verbs to deliver IP packets? This is not only for Ethernet. Internally Infiniband is frequently used and there also timestamps are useful. > Having a conversion function, or doing it in the wc generation is more > 'obviously safe' for future proofing the UAPI. Well no. There has been a history of putting time corrections etc etc into these. Once you move from a raw counter to actual time various complications may need to be dealt with. For simple time differentials the counter is sufficient. If you really want proper "time" when something happens then you may want to scale and correct etc the value and have some sort of time sync approach. > > But that requires additional processing. > > Well, it is only additional if the app is going to ignore the time > stamp or not convert it to ns right away. Is that the common use case? The app may not need proper time but just a cycle count differential. A cycle count differential is often easier to handle than a ns value. And having ns values leads to the assumption that they are "correct" so various factors related to tuning the clock etc may have to be applied. You want to deal with these issues only if really necessary. -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
