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 <dledf...@redhat.com>
GPG KeyID: 0E572FDD
signature.asc
Description: This is a digitally signed message part
