On Fri, 29 May 2015, Hefty, Sean wrote: > > What is the issue here? The timestamp is created when the processing is > > finished by the nic and the completion entry becomes available. > > The timestamp is generated when a work completion entry is written. If the= > re's a clear use case for this, it hasn't been described. The use case you= > mentioned only works if there is a 1:1 relationship between a packet and a= > work completion. That is not what is being defined here.
It does make sense to have a timestamp when the work described by a CQ has been completed. For that you do not need a 1:1 correspondence. My use case is focused on single packet processing because that is what we do here. > > It is exactly defined like any other cycle counters in hardware and it is > > exposed using an API that allows multiple vendors to use these cycle > > counters without regard to a particular vendors implementation. > > I disagree. This is associated with a specific implementation. It assumes= > that the counter is part of a CQ entry, and that the counter is written wh= > en the completion is written. There's nothing that requires other vendors = > to follow that model, nor is it clear that this is a generic or useful enou= > gh operation that other vendors would want to follow this model. Why not h= > ave the time stamp record the start of the transaction? The end? Have two= > stamps, once for the first packet, and one for the last? Limit this to si= > ngle packet operations only? Why would you have a timestamp at the beginning of the transaction? That is useless because you can use packet capture devices to establish that timepoint. At that point you have not identified the CQ anyways. Having a timestamp when an action is complete makes sense, is generic and general. Adding the timestamp to the data means that the application now has to separate the metadata (timestamp) from the data stream. Not good. -- 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
