From: Brelinski, TonyX <tonyx.brelinski@intel.com>
To: intel-wired-lan@osuosl.org
Subject: [Intel-wired-lan] [PATCH v2 7/8] ice: enable receive hardware timestamping
Date: Thu, 10 Jun 2021 21:21:19 +0000 [thread overview]
Message-ID: <CO1PR11MB510566E0C9A47F6D53DA8FB3FA359@CO1PR11MB5105.namprd11.prod.outlook.com> (raw)
In-Reply-To: <20210609163953.52440-8-anthony.l.nguyen@intel.com>
> -----Original Message-----
> From: Intel-wired-lan <intel-wired-lan-bounces@osuosl.org> On Behalf Of
> Tony Nguyen
> Sent: Wednesday, June 9, 2021 9:40 AM
> To: intel-wired-lan at lists.osuosl.org
> Subject: [Intel-wired-lan] [PATCH v2 7/8] ice: enable receive hardware
> timestamping
>
> From: Jacob Keller <jacob.e.keller@intel.com>
>
> Add SIOCGHWTSTAMP and SIOCSHWTSTAMP ioctl handlers to respond to
> requests to enable timestamping support. If the request is for enabling Rx
> timestamps, set a bit in the Rx descriptors to indicate that receive
> timestamps should be reported.
>
> Hardware captures receive timestamps in the PHY which only captures part
> of the timer, and reports only 40 bits into the Rx descriptor. The upper
> 32 bits represent the contents of GLTSYN_TIME_L at the point of packet
> reception, while the lower 8 bits represent the upper 8 bits of
> GLTSYN_TIME_0.
>
> The networking and PTP stack expect 64 bit timestamps in nanoseconds. To
> support this, implement some logic to extend the timestamps by using the
> full PHC time.
>
> If the Rx timestamp was captured prior to the PHC time, then the real
> timestamp is
>
> PHC - (lower_32_bits(PHC) - timestamp)
>
> If the Rx timestamp was captured after the PHC time, then the real
> timestamp is
>
> PHC + (timestamp - lower_32_bits(PHC))
>
> These calculations are correct as long as neither the PHC timestamp nor the
> Rx timestamps are more than 2^32-1 nanseconds old. Further, we can detect
> when the Rx timestamp is before or after the PHC as long as the PHC
> timestamp is no more than 2^31-1 nanoseconds old.
>
> In that case, we calculate the delta between the lower 32 bits of the PHC and
> the Rx timestamp. If it's larger than 2^31-1 then the Rx timestamp must have
> been captured in the past. If it's smaller, then the Rx timestamp must have
> been captured after PHC time.
>
> Add an ice_ptp_extend_32b_ts function that relies on a cached copy of the
> PHC time and implements this algorithm to calculate the proper upper 32bits
> of the Rx timestamps.
>
> Cache the PHC time periodically in all of the Rx rings. This enables each Rx ring
> to simply call the extension function with a recent copy of the PHC time. By
> ensuring that the PHC time is kept up to date periodically, we ensure this
> algorithm doesn't use stale data and produce incorrect results.
>
> To cache the time, introduce a kworker and a kwork item to periodically store
> the Rx time. It might seem like we should use the .do_aux_work interface of
> the PTP clock. This doesn't work because all PFs must cache this time, but
> only one PF owns the PTP clock device.
>
> Thus, the ice driver will manage its own kthread instead of relying on the PTP
> do_aux_work handler.
>
> With this change, the driver can now report Rx timestamps on all incoming
> packets.
>
> Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
> ---
> drivers/net/ethernet/intel/ice/ice_base.c | 5 +-
> drivers/net/ethernet/intel/ice/ice_ethtool.c | 7 +-
> drivers/net/ethernet/intel/ice/ice_lib.c | 8 +-
> drivers/net/ethernet/intel/ice/ice_lib.h | 3 +-
> drivers/net/ethernet/intel/ice/ice_main.c | 22 ++
> drivers/net/ethernet/intel/ice/ice_ptp.c | 337 ++++++++++++++++++
> drivers/net/ethernet/intel/ice/ice_ptp.h | 28 ++
> drivers/net/ethernet/intel/ice/ice_txrx.h | 2 +
> drivers/net/ethernet/intel/ice/ice_txrx_lib.c | 3 +
> 9 files changed, 409 insertions(+), 6 deletions(-)
Tested-by: Tony Brelinski <tonyx.brelinski@intel.com> (A Contingent Worker at Intel)
next prev parent reply other threads:[~2021-06-10 21:21 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-06-09 16:39 [Intel-wired-lan] [PATCH v2 0/8] ice: implement PTP clock for E810 devices Tony Nguyen
2021-06-09 16:39 ` [Intel-wired-lan] [PATCH v2 1/8] ice: add support for sideband messages Tony Nguyen
2021-06-10 20:03 ` Brelinski, TonyX
2021-06-09 16:39 ` [Intel-wired-lan] [PATCH v2 2/8] ice: process 1588 PTP capabilities during initialization Tony Nguyen
2021-06-10 20:04 ` Brelinski, TonyX
2021-06-09 16:39 ` [Intel-wired-lan] [PATCH v2 3/8] ice: add support for set/get of driver-stored firmware parameters Tony Nguyen
2021-06-10 21:16 ` Brelinski, TonyX
2021-06-09 16:39 ` [Intel-wired-lan] [PATCH v2 4/8] ice: add low level PTP clock access functions Tony Nguyen
2021-06-10 21:19 ` Brelinski, TonyX
2021-06-09 16:39 ` [Intel-wired-lan] [PATCH v2 5/8] ice: register 1588 PTP clock device object for E810 devices Tony Nguyen
2021-06-10 21:19 ` Brelinski, TonyX
2021-06-09 16:39 ` [Intel-wired-lan] [PATCH v2 6/8] ice: report the PTP clock index in ethtool .get_ts_info Tony Nguyen
2021-06-10 21:20 ` Brelinski, TonyX
2021-06-09 16:39 ` [Intel-wired-lan] [PATCH v2 7/8] ice: enable receive hardware timestamping Tony Nguyen
2021-06-10 21:21 ` Brelinski, TonyX [this message]
2021-06-09 16:39 ` [Intel-wired-lan] [PATCH v2 8/8] ice: enable transmit timestamps for E810 devices Tony Nguyen
2021-06-10 21:34 ` Brelinski, TonyX
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=CO1PR11MB510566E0C9A47F6D53DA8FB3FA359@CO1PR11MB5105.namprd11.prod.outlook.com \
--to=tonyx.brelinski@intel.com \
--cc=intel-wired-lan@osuosl.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.