DPDK patches and discussions
 help / color / mirror / Atom feed
From: Olivier Matz <olivier.matz@6wind.com>
To: PATRICK KEROULAS <patrick.keroulas@radio-canada.ca>
Cc: Vivien Didelot <vivien.didelot@gmail.com>,
	dev@dpdk.org, Ferruh Yigit <ferruh.yigit@intel.com>,
	Slava Ovsiienko <viacheslavo@mellanox.com>
Subject: Re: [dpdk-dev] [RFC PATCH 3/3] net/pcap: support hardware Tx timestamps
Date: Tue, 7 Jul 2020 16:47:29 +0200	[thread overview]
Message-ID: <20200707144729.GK5869@platinum> (raw)
In-Reply-To: <CALEF-=CWOgTiUDTxqngx7_StG0xap4qGWEWz9uzU7SxqB9U78g@mail.gmail.com>

Hi Patrick,

On Mon, Jul 06, 2020 at 02:36:30PM -0400, PATRICK KEROULAS wrote:
> On Fri, Jun 26, 2020 at 2:48 AM Olivier Matz <olivier.matz@6wind.com> wrote:
> > I don't get why you expect that timestamp to be in nanoseconds.
> > The conversion is done in librte_pdump (in the previous patch),
> > but it won't work if the library is not used, right?
> >
> You're right Olivier. I took advantage of the definition of mbuf->timestamp
> as being "not normalized". The proposed conversion needs NIC clock info
> which can't be accessed from the secondary process. Do you have a better
> suggestion? Should I set a user flag in mbuf for nanoseconds?
> > Out of curiosity, can you explain your motivation for using the hardware
> > timestamp? Is it faster? More accurate? (knowing it timestamps the Rx
> > operation, not the Tx)
> Accuracy is our requirement in the broadcast industry (and probably
> in finance as well) where core systems are very time sensitive. Our
> application uses the NIC mostly as a receiver for UDP stream monitoring
> in order to measure the network propagation delay and jitter. Using SW Rx
> timestamps completely breaks this requirement.

OK, your main motivation for hardware timestamping is the accuracy, and
your application logs the Rx timestamp into the pcap when using the PMD.

For the pmd pcap part, the dynamic Tx timestamp flag that is being
introduced by Slava [1] may fit your needs: ie. when the flag is set, it
uses the provided timestamp which should be in nanosecs.

[1] https://patchwork.dpdk.org/patch/73427/

For the conversion from hardware Rx timestamp into Tx timestamp (in
nanosec), could it be done by your application? Early in the Rx path, if
a packet has a Rx timestamp flag, do the conversion to nsecs, and set
the timestamp field and the Tx timestamp flag.


  reply	other threads:[~2020-07-07 14:47 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-06-25 19:01 [dpdk-dev] [RFC PATCH 0/3] mlx5 to PCAP capture with hardware timestamps Vivien Didelot
2020-06-25 19:01 ` [dpdk-dev] [RFC PATCH 1/3] net/mlx5: add timestamp-to-ns converter from libibverbs Vivien Didelot
2020-06-26  6:41   ` Olivier Matz
2020-07-07 15:23     ` PATRICK KEROULAS
2020-06-25 19:01 ` [dpdk-dev] [RFC PATCH 2/3] ethdev: add API to convert raw timestamps to nsec Vivien Didelot
2020-06-25 19:01 ` [dpdk-dev] [RFC PATCH 3/3] net/pcap: support hardware Tx timestamps Vivien Didelot
2020-06-26  6:48   ` Olivier Matz
2020-07-06 18:36     ` PATRICK KEROULAS
2020-07-07 14:47       ` Olivier Matz [this message]
2020-07-10 19:23         ` PATRICK KEROULAS
2020-06-30 14:59   ` Stephen Hemminger
2020-07-08 14:34 ` [dpdk-dev] [RFC PATCH 0/3] mlx5 to PCAP capture with hardwaretimestamps Morten Brørup

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:

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

  git send-email \
    --in-reply-to=20200707144729.GK5869@platinum \
    --to=olivier.matz@6wind.com \
    --cc=dev@dpdk.org \
    --cc=ferruh.yigit@intel.com \
    --cc=patrick.keroulas@radio-canada.ca \
    --cc=viacheslavo@mellanox.com \
    --cc=vivien.didelot@gmail.com \


* 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).