> > > Second: What about wrap around? Does it even make sense to expose less > > > than 64 bits to userspace? Should the driver manage wrap around to > > > create a flat 64 bit space? > > > > The wrap around is given by the mask. Cycle registers are often shorter > > than 64 bits. > > I am aware of how cycle counters work. > > My point was exposing raw wrapping counters is a horrible UAPI. > > Shouldn't the driver software extend smaller counters to 64 bits? > That would take a single or and an unlikely branch, so don't say > 'performance' :)
It's one thing to time stamp a frame or packet. But this is assigning a time stamp to a work completion. I don't even know what that's supposed to mean when considering 2 GB (or larger) transfers, RDMA read operations, XRC, dynamic connections, out of order retransmissions, shared receive queues, and other exotic features. IMO, this is currently vendor specific functionality, and not obviously applicable as a generic feature. It is certainly poorly defined and exposed in a very implementation specific way. The use case given by Christoph only speaks of packet level time stamps. One could argue that such a use case would place the stamp near the packet (similar to the GRH), rather than embedded into a work completion. This would allow time stamps even in the absence of a work completion. IMO, vendors already have ways to expose vendor specific features to user space. I would mark this as vendor specific and keep it out of the core. - Sean -- 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
