DPDK patches and discussions
 help / color / mirror / Atom feed
From: Vivien Didelot <vivien.didelot@gmail.com>
To: Olivier Matz <olivier.matz@6wind.com>
Cc: Ferruh Yigit <ferruh.yigit@intel.com>,
	dev@dpdk.org, PATRICK KEROULAS <patrick.keroulas@radio-canada.ca>
Subject: Re: [dpdk-dev] [PATCH] net/pcap: support hardware Tx timestamps
Date: Thu, 25 Jun 2020 14:49:37 -0400	[thread overview]
Message-ID: <20200625144937.GB260035@t480s.localdomain> (raw)
In-Reply-To: <20200625163532.GU12564@platinum>

Hi Olivier,

On Thu, 25 Jun 2020 18:35:32 +0200, Olivier Matz <olivier.matz@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

  reply	other threads:[~2020-06-30  7:32 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-06-10 19:39 Vivien Didelot
2020-06-16 19:02 ` Vivien Didelot
2020-06-17  8:16 ` Ferruh Yigit
2020-06-23 22:10   ` Vivien Didelot
2020-06-25 16:35     ` Olivier Matz
2020-06-25 18:49       ` Vivien Didelot [this message]
2020-06-26 13:52         ` Ferruh Yigit

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200625144937.GB260035@t480s.localdomain \
    --to=vivien.didelot@gmail.com \
    --cc=dev@dpdk.org \
    --cc=ferruh.yigit@intel.com \
    --cc=olivier.matz@6wind.com \
    --cc=patrick.keroulas@radio-canada.ca \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).