From: PATRICK KEROULAS <patrick.keroulas@radio-canada.ca>
To: Olivier Matz <olivier.matz@6wind.com>
Cc: Vivien Didelot <vivien.didelot@gmail.com>,
dev@dpdk.org, Ferruh Yigit <ferruh.yigit@intel.com>
Subject: Re: [dpdk-dev] [RFC PATCH 3/3] net/pcap: support hardware Tx timestamps
Date: Mon, 6 Jul 2020 14:36:30 -0400 [thread overview]
Message-ID: <CALEF-=CWOgTiUDTxqngx7_StG0xap4qGWEWz9uzU7SxqB9U78g@mail.gmail.com> (raw)
In-Reply-To: <20200626064817.GW12564@platinum>
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.
next prev parent reply other threads:[~2020-07-06 18:36 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 [this message]
2020-07-07 14:47 ` Olivier Matz
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:
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='CALEF-=CWOgTiUDTxqngx7_StG0xap4qGWEWz9uzU7SxqB9U78g@mail.gmail.com' \
--to=patrick.keroulas@radio-canada.ca \
--cc=dev@dpdk.org \
--cc=ferruh.yigit@intel.com \
--cc=olivier.matz@6wind.com \
--cc=vivien.didelot@gmail.com \
/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).