> > If I were adding timestamps, I would probably define a new completion > > structure with 2 u64 time stamp fields (start and end times), and figure > > out when start occurred, end occurred, and the timing metric later. :) > > Not sure why you would need the start. The app knows when it submitted a > send request and incoming packets can be readily timed with taps if > necessary. If you want the start on inbound packets then you have the > challenge that the adapter needs to figure out when the first bit of the > message actually arrived and the timestamp information needs to be pushed > through all the way through the pipeline. Completion is easily done.
You're assuming that the only start time of interest is when a send operation has been posted. Jason asked what I would do with libfabric. That interface supports triggered operations. It has also been designed such that a rendezvous (that has to be one of the most difficult words in the English language to spell correctly, even with spell check) protocol could be implemented by the provider. On the receive side, it may be of interest to report the start and ending time for larger transfers, primarily for debugging purposes. I have no idea how the time stamps are expected to be used, so why limit it? An app could just as easily create their own time stamp when reading a work completion, especially when the data is going into an anonymous receive buffer. That would seem to work for your use case. > > I would assume that these are non-wrapping values. > > Its fine what we have now as far as I can tell. > > I am not sure why it is necessary to make this more complicated than it is > now. We need a simple means to obtain the completion time and that is what > the current implementation provides. There is even another vendor > (chelsio) who has a similar implementation. And I thought Chelsio they mentioned that they have 2 time stamps. I have no problem with a bare metal interface exposing this. But pretending that it's generic and that this is the one and only way that this could be implemented doesn't make it so. -- 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
