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

[Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>]

[-- 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 --]