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

Doug Ledford
2015-05-29T17:14:48Z

[-- Attachment #1: Type: text/plain, Size: 1944 bytes --]

On Fri, 2015-05-29 at 17:09 +0000, Hefty, Sean wrote:
> > Now, as a general rule, I would call timestamps general. They should be
> > added in a fashion that anyone can implement. They should also be well
> > defined. Sean's questions raise a very valid point. Exactly what is
> > being timestamped, and do we care about different timestamp options? Is
> > it completion of message, start of message, transfer from HCA to main
> > system memory completion, etc. The 00/10 header to this patch series
> > was probably answering Sean's question, but just based on the name of
> > the TIMESTAMP flag to the CQ creation attr struct it isn't clear that
> > this is the case.
>
> I didn't see the information that I was looking for in the patch header to this series. As Jason pointed out, the use case is lacking.
>
> IMO, it could make just as much sense to associate/enable time stamping with the QP as with the CQ, or even make it configurable per operation or operation type.
>
> If Christoph has a clear use case and wants to go to the 'bare metal', then a vendor specific option seems ideal. At least until there are other implementations or the driving use case is clearer.

The use case is clear IMO. It's for financial trading software. I
don't think they really care about details like whether it's the start
or end packet, or completion, or whatever. They need a tie breaker
between when they have two different buy or sell orders on the same lot
of stock. Any deterministic timing/ordering method will do as long as
they consistently apply it I think. And the faster and lower overhead
the process, the better. He doesn't really want a timestamp, he merely
wants a sequence ordering. But a timestamp is what they are using to
get him what he needs.

Is that a fair guess Christoph?

--
Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
GPG KeyID: 0E572FDD

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 819 bytes --]