From: Jakub Kicinski <kuba@kernel.org>
To: "Zulkifli, Muhammad Husaini" <muhammad.husaini.zulkifli@intel.com>
Cc: "leon@kernel.org" <leon@kernel.org>,
"intel-wired-lan@osuosl.org" <intel-wired-lan@osuosl.org>,
Richard Cochran <richardcochran@gmail.com>,
Saeed Mahameed <saeed@kernel.org>,
"edumazet@google.com" <edumazet@google.com>,
Gal Pressman <gal@nvidia.com>,
"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
Michael Chan <michael.chan@broadcom.com>,
"davem@davemloft.net" <davem@davemloft.net>,
Andy Gospodarek <andy@greyhouse.net>,
"Ahmad Tarmizi, Noor Azura" <noor.azura.ahmad.tarmizi@intel.com>
Subject: Re: [Intel-wired-lan] [PATCH v1 0/4] Add support for DMA timestamp for non-PTP packets
Date: Fri, 30 Sep 2022 07:40:16 -0700 [thread overview]
Message-ID: <20220930074016.295cbfab@kernel.org> (raw)
In-Reply-To: <SJ1PR11MB61808A055419C257F6B653CCB8569@SJ1PR11MB6180.namprd11.prod.outlook.com>
On Fri, 30 Sep 2022 08:52:38 +0000 Zulkifli, Muhammad Husaini wrote:
> > > Yes. HW timestamps always can be assume equivalent to PTP quality.
> > > Could you provide additional information regarding SFD crosses the RS
> > > layer?
> >
> > I mean true PTP timestamps, rather than captured somewhere in the NIC
> > pipeline or at the DMA engine.
>
> When SOF_TIMESTAMPING_TX_HARDWARE is been used, we guaranteed a PTP quality
> Timestamps (timestamp capture when packet leave the wire upon sensing the SFD).
> As of SOF_TIMESTAMPING_TX_HARDWARE_DMA_FETCH, it is not a PTP quality because
> the HW timestamp reported in this case, is a time when the data is
> DMA'ed into the NIC packet buffer.
I understand that _your_ device does it right.
But there are vendors out there who treat SOF_TIMESTAMPING_TX_HARDWARE
as your new SOF_TIMESTAMPING_TX_HARDWARE_DMA_FETCH.
> > > Yes, you're right. Are you suggesting that we add a new tx_type to
> > > specify Only MAC/PHY timestamp ? Ex. HWTSTAMP_TX_PHY/MAC_ON.
> >
> > Perhaps we can call them HWTSTAMP_TX_PTP_* ? Was the general time
> > stamping requirement specified in IEEE 1588 or 802.1 (AS?)?
> >
> > Both MAC and PHY can provide the time stamps IIUC, so picking one of those
> > will not be entirely fortunate. In fact perhaps embedded folks will use this
> > opportunity to disambiguate the two..
>
> With the help of SOF_TIMESTAMPING_TX_HARDWARE, we will get the
> PHY level timestamp(PTP quality) while using SOF_TIMESTAMPING_TX_HARDWARE_DMA_FETCH,
> we will get the timestamp at a point in the NIC pipeline.
>
> Linuxptp application uses SOF_TIMESTAMPING_TX_HARDWARE for their socket option.
> And this can guarantee a PTP quality timestamp.
>
> Can we just use a SOF_TIMESTAMPING to identify which timestamp that we want rather
> than creating a new tx_type?
Hm, perhaps, yes, we can stick to that.
_______________________________________________
Intel-wired-lan mailing list
Intel-wired-lan@osuosl.org
https://lists.osuosl.org/mailman/listinfo/intel-wired-lan
WARNING: multiple messages have this Message-ID (diff)
From: Jakub Kicinski <kuba@kernel.org>
To: "Zulkifli, Muhammad Husaini" <muhammad.husaini.zulkifli@intel.com>
Cc: "intel-wired-lan@osuosl.org" <intel-wired-lan@osuosl.org>,
"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
"davem@davemloft.net" <davem@davemloft.net>,
"edumazet@google.com" <edumazet@google.com>,
"Gomes, Vinicius" <vinicius.gomes@intel.com>,
"Gunasekaran, Aravindhan" <aravindhan.gunasekaran@intel.com>,
"Ahmad Tarmizi, Noor Azura" <noor.azura.ahmad.tarmizi@intel.com>,
Richard Cochran <richardcochran@gmail.com>,
Gal Pressman <gal@nvidia.com>, Saeed Mahameed <saeed@kernel.org>,
"leon@kernel.org" <leon@kernel.org>,
Michael Chan <michael.chan@broadcom.com>,
Andy Gospodarek <andy@greyhouse.net>
Subject: Re: [PATCH v1 0/4] Add support for DMA timestamp for non-PTP packets
Date: Fri, 30 Sep 2022 07:40:16 -0700 [thread overview]
Message-ID: <20220930074016.295cbfab@kernel.org> (raw)
In-Reply-To: <SJ1PR11MB61808A055419C257F6B653CCB8569@SJ1PR11MB6180.namprd11.prod.outlook.com>
On Fri, 30 Sep 2022 08:52:38 +0000 Zulkifli, Muhammad Husaini wrote:
> > > Yes. HW timestamps always can be assume equivalent to PTP quality.
> > > Could you provide additional information regarding SFD crosses the RS
> > > layer?
> >
> > I mean true PTP timestamps, rather than captured somewhere in the NIC
> > pipeline or at the DMA engine.
>
> When SOF_TIMESTAMPING_TX_HARDWARE is been used, we guaranteed a PTP quality
> Timestamps (timestamp capture when packet leave the wire upon sensing the SFD).
> As of SOF_TIMESTAMPING_TX_HARDWARE_DMA_FETCH, it is not a PTP quality because
> the HW timestamp reported in this case, is a time when the data is
> DMA'ed into the NIC packet buffer.
I understand that _your_ device does it right.
But there are vendors out there who treat SOF_TIMESTAMPING_TX_HARDWARE
as your new SOF_TIMESTAMPING_TX_HARDWARE_DMA_FETCH.
> > > Yes, you're right. Are you suggesting that we add a new tx_type to
> > > specify Only MAC/PHY timestamp ? Ex. HWTSTAMP_TX_PHY/MAC_ON.
> >
> > Perhaps we can call them HWTSTAMP_TX_PTP_* ? Was the general time
> > stamping requirement specified in IEEE 1588 or 802.1 (AS?)?
> >
> > Both MAC and PHY can provide the time stamps IIUC, so picking one of those
> > will not be entirely fortunate. In fact perhaps embedded folks will use this
> > opportunity to disambiguate the two..
>
> With the help of SOF_TIMESTAMPING_TX_HARDWARE, we will get the
> PHY level timestamp(PTP quality) while using SOF_TIMESTAMPING_TX_HARDWARE_DMA_FETCH,
> we will get the timestamp at a point in the NIC pipeline.
>
> Linuxptp application uses SOF_TIMESTAMPING_TX_HARDWARE for their socket option.
> And this can guarantee a PTP quality timestamp.
>
> Can we just use a SOF_TIMESTAMPING to identify which timestamp that we want rather
> than creating a new tx_type?
Hm, perhaps, yes, we can stick to that.
next prev parent reply other threads:[~2022-09-30 14:40 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-09-27 13:06 [Intel-wired-lan] [PATCH v1 0/4] Add support for DMA timestamp for non-PTP packets Muhammad Husaini Zulkifli
2022-09-27 13:06 ` Muhammad Husaini Zulkifli
2022-09-27 13:06 ` [Intel-wired-lan] [PATCH v1 1/4] ethtool: Add new hwtstamp flag Muhammad Husaini Zulkifli
2022-09-27 13:06 ` Muhammad Husaini Zulkifli
2022-09-28 0:11 ` [Intel-wired-lan] " Jakub Kicinski
2022-09-28 0:11 ` Jakub Kicinski
2022-09-29 3:40 ` [Intel-wired-lan] " Zulkifli, Muhammad Husaini
2022-09-29 3:40 ` Zulkifli, Muhammad Husaini
2022-09-27 13:06 ` [Intel-wired-lan] [PATCH v1 2/4] net-timestamp: Increase the size of tsflags Muhammad Husaini Zulkifli
2022-09-27 13:06 ` Muhammad Husaini Zulkifli
2022-09-27 13:06 ` [Intel-wired-lan] [PATCH v1 3/4] net: sock: extend SO_TIMESTAMPING for DMA Fetch Muhammad Husaini Zulkifli
2022-09-27 13:06 ` Muhammad Husaini Zulkifli
2022-09-27 13:06 ` [Intel-wired-lan] [PATCH v1 4/4] igc: Add support for DMA timestamp for non-PTP packets Muhammad Husaini Zulkifli
2022-09-27 13:06 ` Muhammad Husaini Zulkifli
2022-09-27 15:27 ` [Intel-wired-lan] [PATCH v1 0/4] " Andrew Lunn
2022-09-27 15:27 ` Andrew Lunn
2022-09-29 2:22 ` [Intel-wired-lan] " Zulkifli, Muhammad Husaini
2022-09-29 2:22 ` Zulkifli, Muhammad Husaini
2022-09-28 0:09 ` [Intel-wired-lan] " Jakub Kicinski
2022-09-28 0:09 ` Jakub Kicinski
2022-09-29 2:35 ` [Intel-wired-lan] " Zulkifli, Muhammad Husaini
2022-09-29 2:35 ` Zulkifli, Muhammad Husaini
2022-09-29 13:56 ` [Intel-wired-lan] " Jakub Kicinski
2022-09-29 13:56 ` Jakub Kicinski
2022-09-29 14:46 ` [Intel-wired-lan] " Gal Pressman
2022-09-29 14:46 ` Gal Pressman
2022-09-29 15:23 ` [Intel-wired-lan] " Jakub Kicinski
2022-09-29 15:23 ` Jakub Kicinski
2022-09-30 8:52 ` [Intel-wired-lan] " Zulkifli, Muhammad Husaini
2022-09-30 8:52 ` Zulkifli, Muhammad Husaini
2022-09-30 14:40 ` Jakub Kicinski [this message]
2022-09-30 14:40 ` Jakub Kicinski
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=20220930074016.295cbfab@kernel.org \
--to=kuba@kernel.org \
--cc=andy@greyhouse.net \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=gal@nvidia.com \
--cc=intel-wired-lan@osuosl.org \
--cc=leon@kernel.org \
--cc=michael.chan@broadcom.com \
--cc=muhammad.husaini.zulkifli@intel.com \
--cc=netdev@vger.kernel.org \
--cc=noor.azura.ahmad.tarmizi@intel.com \
--cc=richardcochran@gmail.com \
--cc=saeed@kernel.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.