Hi Tom, Tuesday, September 4, 2018 5:26 PM, Tom Barbette: >
>Hi all, > >As far as I know, MLX5 is the only driver to support hardware timestamping. > >It would be great to update the doc to explain what the hardware timestamp is >supposed to be. We probably need to update the doc, but the current timestamp support is very basic. It just provide a raw timestamp from the NIC running clock. The granularity of each “tick” is undefined. It is not yet the full IEEE1588 you seek to put all the events in the system on a single time axis. >If it's nanoseconds, then just a shift regarding system time is enough ? Does >it also need a >multiplication? Can we query that from hardware? Or provide a >piece of code to be used. As it, the feature >is useless... Unfortunately we lack the APIs to query the offset and multiplication factor from the device/kernel. This is why the current feature is very basic. It can be used only to understand the order of the events at the NIC (for example if one packet passed the NIC before the other), however one cannot understand the absolute diff between 2 events in a common clock granularity. > >It would be interesting to normalize the hardware timestamping. I guess for >any driver, an offset and a multiplication(shift+multiplier eventually) would >be enough, and the API should be updated to >provide a function to convert a >hardware timestamp to software (or that should be part of the driver and done >automatically if offloading is enabled?) and probably one to initialize the >time, much >like the Linux one at >https://elixir.bootlin.com/linux/v4.18.5/source/drivers/net/ethernet/mellanox/mlx5/core/lib/clock.c#L488<https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Felixir.bootlin.com%2Flinux%2Fv4.18.5%2Fsource%2Fdrivers%2Fnet%2Fethernet%2Fmellanox%2Fmlx5%2Fcore%2Flib%2Fclock.c%23L488&data=02%7C01%7Cshahafs%40mellanox.com%7Ce1623f43e33c4c9e2a3308d612726753%7Ca652971c7d2e4d9ba6a4d149256f461b%7C0%7C0%7C636716679902892854&sdata=Xus3oma6Rig2AAxrBCUNgSvWx1NSYSbiFO0ei%2Bz0R40%3D&reserved=0> > . Of course, when we will have the APIs to support it, the PMD will do the conversion into the real clock units, no need for the application to do it by itself. It will be interesting to me to completely understand your use case in order to evaluate the need and priority for such API. > >Thanks,
