All of lore.kernel.org
 help / color / mirror / Atom feed
From: Leon Romanovsky <leon@kernel.org>
To: Selvin Xavier <selvin.xavier@broadcom.com>
Cc: jgg@ziepe.ca, linux-rdma@vger.kernel.org,
	andrew.gospodarek@broadcom.com, kashyap.desai@broadcom.com
Subject: Re: [PATCH v2 for-next 05/17] RDMA/bnxt_re: Enhance the existing functions that wait for FW responses
Date: Mon, 12 Jun 2023 10:00:48 +0300	[thread overview]
Message-ID: <20230612070048.GN12152@unreal> (raw)
In-Reply-To: <1686308514-11996-6-git-send-email-selvin.xavier@broadcom.com>

On Fri, Jun 09, 2023 at 04:01:42AM -0700, Selvin Xavier wrote:
> From: Kashyap Desai <kashyap.desai@broadcom.com>
> 
> Use jiffies based timewait instead of counting iteration for
> commands that block for FW response.
> 
> Also add a poll routine for control path commands. This is for
> polling completion if the waiting commands timeout. This avoids cases
> where the driver misses completion interrupts.
> 
> Signed-off-by: Kashyap Desai <kashyap.desai@broadcom.com>
> Signed-off-by: Selvin Xavier <selvin.xavier@broadcom.com>
> ---
>  drivers/infiniband/hw/bnxt_re/qplib_rcfw.c | 65 +++++++++++++++++++++++-------
>  1 file changed, 51 insertions(+), 14 deletions(-)
> 
> diff --git a/drivers/infiniband/hw/bnxt_re/qplib_rcfw.c b/drivers/infiniband/hw/bnxt_re/qplib_rcfw.c
> index 66121fb..3b242cc 100644
> --- a/drivers/infiniband/hw/bnxt_re/qplib_rcfw.c
> +++ b/drivers/infiniband/hw/bnxt_re/qplib_rcfw.c
> @@ -53,37 +53,74 @@
>  
>  static void bnxt_qplib_service_creq(struct tasklet_struct *t);
>  
> -/* Hardware communication channel */
> +/**
> + * __wait_for_resp   -	Don't hold the cpu context and wait for response
> + * @rcfw      -   rcfw channel instance of rdev
> + * @cookie    -   cookie to track the command
> + *
> + * Wait for command completion in sleepable context.
> + *
> + * Returns:
> + * 0 if command is completed by firmware.
> + * Non zero error code for rest of the case.

I don't see "return ret;" in this function.

> + */
>  static int __wait_for_resp(struct bnxt_qplib_rcfw *rcfw, u16 cookie)
>  {
>  	struct bnxt_qplib_cmdq_ctx *cmdq;
>  	u16 cbit;
> -	int rc;
> +	int ret;
>  
>  	cmdq = &rcfw->cmdq;
>  	cbit = cookie % rcfw->cmdq_depth;
> -	rc = wait_event_timeout(cmdq->waitq,
> -				!test_bit(cbit, cmdq->cmdq_bitmap),
> -				msecs_to_jiffies(RCFW_CMD_WAIT_TIME_MS));
> -	return rc ? 0 : -ETIMEDOUT;
> +
> +	do {
> +		/* Non zero means command completed */
> +		ret = wait_event_timeout(cmdq->waitq,
> +					 !test_bit(cbit, cmdq->cmdq_bitmap),
> +					 msecs_to_jiffies(10000));

Don't you need to check ret here?

> +
> +		if (!test_bit(cbit, cmdq->cmdq_bitmap))
> +			return 0;
> +
> +		bnxt_qplib_service_creq(&rcfw->creq.creq_tasklet);
> +
> +		if (!test_bit(cbit, cmdq->cmdq_bitmap))
> +			return 0;
> +
> +	} while (true);
>  };
>  
> +/**
> + * __block_for_resp   -	hold the cpu context and wait for response
> + * @rcfw      -   rcfw channel instance of rdev
> + * @cookie    -   cookie to track the command
> + *
> + * This function will hold the cpu (non-sleepable context) and
> + * wait for command completion. Maximum holding interval is 8 second.
> + *
> + * Returns:
> + * -ETIMEOUT if command is not completed in specific time interval.
> + * 0 if command is completed by firmware.
> + */
>  static int __block_for_resp(struct bnxt_qplib_rcfw *rcfw, u16 cookie)
>  {
> -	u32 count = RCFW_BLOCKED_CMD_WAIT_COUNT;
> -	struct bnxt_qplib_cmdq_ctx *cmdq;
> +	struct bnxt_qplib_cmdq_ctx *cmdq = &rcfw->cmdq;
> +	unsigned long issue_time = 0;
>  	u16 cbit;
>  
> -	cmdq = &rcfw->cmdq;
>  	cbit = cookie % rcfw->cmdq_depth;
> -	if (!test_bit(cbit, cmdq->cmdq_bitmap))
> -		goto done;
> +	issue_time = jiffies;
> +
>  	do {
>  		udelay(1);
> +
>  		bnxt_qplib_service_creq(&rcfw->creq.creq_tasklet);
> -	} while (test_bit(cbit, cmdq->cmdq_bitmap) && --count);
> -done:
> -	return count ? 0 : -ETIMEDOUT;
> +		if (!test_bit(cbit, cmdq->cmdq_bitmap))
> +			return 0;
> +
> +	} while (time_before(jiffies, issue_time + (8 * HZ)));
> +
> +	return -ETIMEDOUT;
>  };
>  
>  static int __send_message(struct bnxt_qplib_rcfw *rcfw,
> -- 
> 2.5.5
> 



  reply	other threads:[~2023-06-12  7:39 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-06-09 11:01 [PATCH v2 for-next 00/17] RDMA/bnxt_re: Control path updates Selvin Xavier
2023-06-09 11:01 ` [PATCH v2 for-next 01/17] RDMA/bnxt_re: wraparound mbox producer index Selvin Xavier
2023-06-09 11:01 ` [PATCH v2 for-next 02/17] RDMA/bnxt_re: Avoid calling wake_up threads from spin_lock context Selvin Xavier
2023-06-09 11:01 ` [PATCH v2 for-next 03/17] RDMA/bnxt_re: remove virt_func check while creating RoCE FW channel Selvin Xavier
2023-06-09 11:01 ` [PATCH v2 for-next 04/17] RDMA/bnxt_re: set fixed command queue depth Selvin Xavier
2023-06-09 11:01 ` [PATCH v2 for-next 05/17] RDMA/bnxt_re: Enhance the existing functions that wait for FW responses Selvin Xavier
2023-06-12  7:00   ` Leon Romanovsky [this message]
2023-06-09 11:01 ` [PATCH v2 for-next 06/17] RDMA/bnxt_re: Avoid the command wait if firmware is inactive Selvin Xavier
2023-06-09 11:01 ` [PATCH v2 for-next 07/17] RDMA/bnxt_re: use shadow qd while posting non blocking rcfw command Selvin Xavier
2023-06-09 11:01 ` [PATCH v2 for-next 08/17] RDMA/bnxt_re: Simplify the function that sends the FW commands Selvin Xavier
2023-06-09 11:01 ` [PATCH v2 for-next 09/17] RDMA/bnxt_re: add helper function __poll_for_resp Selvin Xavier
2023-06-12  7:04   ` Leon Romanovsky
2023-06-12  8:01     ` Selvin Xavier
2023-06-09 11:01 ` [PATCH v2 for-next 10/17] RDMA/bnxt_re: handle command completions after driver detect a timedout Selvin Xavier
2023-06-12  7:07   ` Leon Romanovsky
2023-06-09 11:01 ` [PATCH v2 for-next 11/17] RDMA/bnxt_re: Add firmware stall check detection Selvin Xavier
2023-06-09 11:01 ` [PATCH v2 for-next 12/17] RDMA/bnxt_re: post destroy_ah for delayed completion of AH creation Selvin Xavier
2023-06-09 11:01 ` [PATCH v2 for-next 13/17] RDMA/bnxt_re: consider timeout of destroy ah as success Selvin Xavier
2023-06-09 11:01 ` [PATCH v2 for-next 14/17] RDMA/bnxt_re: cancel all control path command waiters upon error Selvin Xavier
2023-06-09 11:01 ` [PATCH v2 for-next 15/17] RDMA/bnxt_re: use firmware provided max request timeout Selvin Xavier
2023-06-09 11:01 ` [PATCH v2 for-next 16/17] RDMA/bnxt_re: remove redundant cmdq_bitmap Selvin Xavier
2023-06-09 11:01 ` [PATCH v2 for-next 17/17] RDMA/bnxt_re: optimize the parameters passed to helper functions Selvin Xavier
2023-06-12  7:12 ` [PATCH v2 for-next 00/17] RDMA/bnxt_re: Control path updates Leon Romanovsky
2023-06-12  7:12 ` Leon Romanovsky

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=20230612070048.GN12152@unreal \
    --to=leon@kernel.org \
    --cc=andrew.gospodarek@broadcom.com \
    --cc=jgg@ziepe.ca \
    --cc=kashyap.desai@broadcom.com \
    --cc=linux-rdma@vger.kernel.org \
    --cc=selvin.xavier@broadcom.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 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.