On Thu, 28 May 2015, Or Gerlitz wrote: > The use case is very clear, low latency applications using UD or RAW PACKET > QPs that needs to know the time it takes for different HW/SW layers to get > their packets through. The verbs version of SO_TIMESTAMP and friends > (Documentation/networking/timestamping*)-- Christoph, can you add some info on > common use-cases for this?
Well timestamp information is widely in the financial industry to track latency and also for fairness. Exchanges/Brokers etc often must guarantee that the packet received first is not processed after packets received later. Packet timestamps in many ways affect processing and are also used for error checking etc. What we have to do without this is to use RDTSC to get a timestamp but the packet reception / sending time then is inaccurate due to the instructions that have to be executed before and after. And there is additional overhead due to that processing. > I bet that > 20 upstream Eth NIC drivers supports time-stamping, so there's no > reason that a modern HCA will not support it too. Right. Ethernet timekeeping support and timestamping has become fairly standard. Even the onboard one do that these days. > > does not implement a standardized feature, > > This is standard in Eth NIC, return the time-stamp of when the packet > arrived/sent It needs desperately to be in the standard. -- 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
