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

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

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.