Hi Olivier,
On Thu, 25 Jun 2020 18:35:32 +0200, Olivier Matz <olivier.m...@6wind.com> wrote:
> As said by Ferruh, the unit of timestamp in mbuf is not normalized to
> nanosecs, as seen in rte_mbuf_core.h:
>
> /** Valid if PKT_RX_TIMESTAMP is set. The unit and time reference
> * are not normalized but are always the same for a given port.
> * Some devices allow to query rte_eth_read_clock that will return the
> * current device timestamp.
> */
> uint64_t timestamp;
>
> Using the timestamp generated from a port which is not a pmd-pcap would
> require a conversion, using rte_eth_read_clock() on mbuf->port (assuming
> it was not modified, which should be true except if event eth Tx adapter
> is used).
>
> Also, note that the timestamp corresponds to the Rx timestamp. I think it
> could be an issue in case the mbuf is reassembled by the application: the
> timestamp in reassembled mbuf would be the one from the first fragment.
>
> So, I share Ferruh's concerns.
I think this is not totally true depending on the driver. For instance, we
use mlx5 which already provides a timestamp conversion to nanosecs through
libibverbs. Let me resend this patch alongside Patrick's mlx5 patches that
implemented the needed glue, so that you may understand better the big picture
of how we enabled hardware timestamping in PCAP capture using mlx5 and pdump.
Regards,
Vivien
