netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Paolo Abeni <pabeni@redhat.com>
To: Tony Nguyen <anthony.l.nguyen@intel.com>,
	davem@davemloft.net, kuba@kernel.org, edumazet@google.com
Cc: Jacob Keller <jacob.e.keller@intel.com>,
	netdev@vger.kernel.org, richardcochran@gmail.com,
	Gurucharan G <gurucharanx.g@intel.com>
Subject: Re: [PATCH net-next 06/14] ice: handle discarding old Tx requests in ice_ptp_tx_tstamp
Date: Thu, 01 Dec 2022 15:58:52 +0100	[thread overview]
Message-ID: <870d718381cea832db341c84ae928ddfc424af64.camel@redhat.com> (raw)
In-Reply-To: <20221130194330.3257836-7-anthony.l.nguyen@intel.com>

On Wed, 2022-11-30 at 11:43 -0800, Tony Nguyen wrote:
> From: Jacob Keller <jacob.e.keller@intel.com>
> 
> Currently the driver uses the PTP kthread to process handling and
> discarding of stale Tx timestamp requests. The function
> ice_ptp_tx_tstamp_cleanup is used for this.
> 
> A separate thread creates complications for the driver as we now have both
> the main Tx timestamp processing IRQ checking timestamps as well as the
> kthread.
> 
> Rather than using the kthread to handle this, simply check for stale
> timestamps within the ice_ptp_tx_tstamp function. This function must
> already process the timestamps anyways.
> 
> If a Tx timestamp has been waiting for 2 seconds we simply clear the bit
> and discard the SKB. This avoids the complication of having separate
> threads polling, reducing overall CPU work.
> 
> Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
> Tested-by: Gurucharan G <gurucharanx.g@intel.com> (A Contingent worker at Intel)
> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
> ---
>  drivers/net/ethernet/intel/ice/ice_ptp.c | 106 ++++++++++-------------
>  1 file changed, 45 insertions(+), 61 deletions(-)
> 
> diff --git a/drivers/net/ethernet/intel/ice/ice_ptp.c b/drivers/net/ethernet/intel/ice/ice_ptp.c
> index 1564c72189bf..58e527f202c0 100644
> --- a/drivers/net/ethernet/intel/ice/ice_ptp.c
> +++ b/drivers/net/ethernet/intel/ice/ice_ptp.c
> @@ -626,15 +626,32 @@ static u64 ice_ptp_extend_40b_ts(struct ice_pf *pf, u64 in_tstamp)
>   * Note that we only take the tracking lock when clearing the bit and when
>   * checking if we need to re-queue this task. The only place where bits can be
>   * set is the hard xmit routine where an SKB has a request flag set. The only
> - * places where we clear bits are this work function, or the periodic cleanup
> - * thread. If the cleanup thread clears a bit we're processing we catch it
> - * when we lock to clear the bit and then grab the SKB pointer. If a Tx thread
> - * starts a new timestamp, we might not begin processing it right away but we
> - * will notice it at the end when we re-queue the task. If a Tx thread starts
> - * a new timestamp just after this function exits without re-queuing,
> - * the interrupt when the timestamp finishes should trigger. Avoiding holding
> - * the lock for the entire function is important in order to ensure that Tx
> - * threads do not get blocked while waiting for the lock.
> + * places where we clear bits are this work function, or when flushing the Tx
> + * timestamp tracker.
> + *
> + * If the Tx tracker gets flushed while we're processing a packet, we catch
> + * this because we grab the SKB pointer under lock. If the SKB is NULL we know
> + * that another thread already discarded the SKB and we can avoid passing it
> + * up to the stack.
> + *
> + * If a Tx thread starts a new timestamp, we might not begin processing it
> + * right away but we will notice it at the end when we re-queue the task.
> + *
> + * If a Tx thread starts a new timestamp just after this function exits, the
> + * interrupt for that timestamp should re-trigger this function once
> + * a timestamp is ready.
> + *
> + * Note that minimizing the time we hold the lock is important. If we held the
> + * lock for the entire function we would unnecessarily block the Tx hot path
> + * which needs to set the timestamp index. Limiting how long we hold the lock
> + * ensures we do not block Tx threads.
> + *
> + * If a Tx packet has been waiting for more than 2 seconds, it is not possible
> + * to correctly extend the timestamp using the cached PHC time. It is
> + * extremely unlikely that a packet will ever take this long to timestamp. If
> + * we detect a Tx timestamp request that has waited for this long we assume
> + * the packet will never be sent by hardware and discard it without reading
> + * the timestamp register.
>   */
>  static bool ice_ptp_tx_tstamp(struct ice_ptp_tx *tx)
>  {
> @@ -653,9 +670,20 @@ static bool ice_ptp_tx_tstamp(struct ice_ptp_tx *tx)
>  		struct skb_shared_hwtstamps shhwtstamps = {};
>  		u8 phy_idx = idx + tx->offset;
>  		u64 raw_tstamp, tstamp;
> +		bool drop_ts = false;
>  		struct sk_buff *skb;
>  		int err;
>  
> +		/* Drop packets which have waited for more than 2 seconds */
> +		if (time_is_before_jiffies(tx->tstamps[idx].start + 2 * HZ)) {
> +			drop_ts = true;
> +
> +			/* Count the number of Tx timestamps that timed out */
> +			pf->ptp.tx_hwtstamp_timeouts++;
> +
> +			goto skip_ts_read;

This skips raw_tstamp initialization and causes later compiler warning
when accessing raw_tstamp.

You probably need to duplicate/factor out a bit of later code to fix
this.

Cheers,

Paolo


  reply	other threads:[~2022-12-01 15:00 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-11-30 19:43 [PATCH net-next 00/14][pull request] Intel Wired LAN Driver Updates 2022-11-30 (ice) Tony Nguyen
2022-11-30 19:43 ` [PATCH net-next 01/14] ice: Use more generic names for ice_ptp_tx fields Tony Nguyen
2022-11-30 19:43 ` [PATCH net-next 02/14] ice: Remove the E822 vernier "bypass" logic Tony Nguyen
2022-11-30 19:43 ` [PATCH net-next 03/14] ice: Reset TS memory for all quads Tony Nguyen
2022-11-30 19:43 ` [PATCH net-next 04/14] ice: fix misuse of "link err" with "link status" Tony Nguyen
2022-11-30 19:43 ` [PATCH net-next 05/14] ice: always call ice_ptp_link_change and make it void Tony Nguyen
2022-11-30 19:43 ` [PATCH net-next 06/14] ice: handle discarding old Tx requests in ice_ptp_tx_tstamp Tony Nguyen
2022-12-01 14:58   ` Paolo Abeni [this message]
2022-12-01 15:04     ` Paolo Abeni
2022-12-02 17:59       ` Jacob Keller
2022-11-30 19:43 ` [PATCH net-next 07/14] ice: check Tx timestamp memory register for ready timestamps Tony Nguyen
2022-11-30 19:43 ` [PATCH net-next 08/14] ice: protect init and calibrating fields with spinlock Tony Nguyen
2022-12-01  9:18   ` Leon Romanovsky
2022-12-02 18:36     ` Jacob Keller
2022-12-02 23:07       ` Jacob Keller
2022-12-04 13:30         ` Leon Romanovsky
2022-12-05 19:57           ` Jacob Keller
2022-11-30 19:43 ` [PATCH net-next 09/14] ice: disable Tx timestamps while link is down Tony Nguyen
2022-11-30 19:43 ` [PATCH net-next 10/14] ice: cleanup allocations in ice_ptp_alloc_tx_tracker Tony Nguyen
2022-11-30 19:43 ` [PATCH net-next 11/14] ice: handle flushing stale Tx timestamps in ice_ptp_tx_tstamp Tony Nguyen
2022-11-30 19:43 ` [PATCH net-next 12/14] ice: only check set bits in ice_ptp_flush_tx_tracker Tony Nguyen
2022-11-30 19:43 ` [PATCH net-next 13/14] ice: make Tx and Rx vernier offset calibration independent Tony Nguyen
2022-11-30 19:43 ` [PATCH net-next 14/14] ice: reschedule ice_ptp_wait_for_offset_valid during reset Tony Nguyen

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=870d718381cea832db341c84ae928ddfc424af64.camel@redhat.com \
    --to=pabeni@redhat.com \
    --cc=anthony.l.nguyen@intel.com \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=gurucharanx.g@intel.com \
    --cc=jacob.e.keller@intel.com \
    --cc=kuba@kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=richardcochran@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).