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 09/17] RDMA/bnxt_re: add helper function __poll_for_resp
Date: Mon, 12 Jun 2023 10:04:17 +0300 [thread overview]
Message-ID: <20230612070417.GO12152@unreal> (raw)
In-Reply-To: <1686308514-11996-10-git-send-email-selvin.xavier@broadcom.com>
On Fri, Jun 09, 2023 at 04:01:46AM -0700, Selvin Xavier wrote:
> From: Kashyap Desai <kashyap.desai@broadcom.com>
>
> This interface will be used if the driver has not enabled interrupt
> and/or interrupt is disabled for a short period of time.
> Completion is not possible from interrupt so this interface does
> self-polling.
>
> 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 | 44 +++++++++++++++++++++++++++++-
> drivers/infiniband/hw/bnxt_re/qplib_rcfw.h | 1 +
> 2 files changed, 44 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/infiniband/hw/bnxt_re/qplib_rcfw.c b/drivers/infiniband/hw/bnxt_re/qplib_rcfw.c
> index 15f6793..3215f8a 100644
> --- a/drivers/infiniband/hw/bnxt_re/qplib_rcfw.c
> +++ b/drivers/infiniband/hw/bnxt_re/qplib_rcfw.c
> @@ -260,6 +260,44 @@ static int __send_message(struct bnxt_qplib_rcfw *rcfw,
> return 0;
> }
>
> +/**
> + * __poll_for_resp - self poll completion for rcfw command
> + * @rcfw - rcfw channel instance of rdev
> + * @cookie - cookie to track the command
> + * @opcode - rcfw submitted for given opcode
> + *
> + * It works same as __wait_for_resp except this function will
> + * do self polling in sort interval since interrupt is disabled.
> + * This function can not be called from non-sleepable context.
> + *
> + * Returns:
> + * -ETIMEOUT if command is not completed in specific time interval.
> + * 0 if command is completed by firmware.
> + */
> +static int __poll_for_resp(struct bnxt_qplib_rcfw *rcfw, u16 cookie,
> + u8 opcode)
> +{
> + struct bnxt_qplib_cmdq_ctx *cmdq = &rcfw->cmdq;
> + unsigned long issue_time;
> + u16 cbit;
> +
> + cbit = cookie % rcfw->cmdq_depth;
> + issue_time = jiffies;
> +
> + do {
> + if (test_bit(ERR_DEVICE_DETACHED, &cmdq->flags))
> + return bnxt_qplib_map_rc(opcode);
> +
> + usleep_range(1000, 1001);
> +
> + bnxt_qplib_service_creq(&rcfw->creq.creq_tasklet);
> + if (!test_bit(cbit, cmdq->cmdq_bitmap))
> + return 0;
> + if (jiffies_to_msecs(jiffies - issue_time) > 10000)
> + return -ETIMEDOUT;
> + } while (true);
> +};
> +
> static int __send_message_basic_sanity(struct bnxt_qplib_rcfw *rcfw,
> struct bnxt_qplib_cmdqmsg *msg)
> {
> @@ -328,8 +366,10 @@ static int __bnxt_qplib_rcfw_send_message(struct bnxt_qplib_rcfw *rcfw,
>
> if (msg->block)
> rc = __block_for_resp(rcfw, cookie, opcode);
> - else
> + else if (atomic_read(&rcfw->rcfw_intr_enabled))
Why atomic_t? It doesn't eliminate the need of locking and if locking
exists, you don't need atomic_t.
> rc = __wait_for_resp(rcfw, cookie, opcode);
> + else
> + rc = __poll_for_resp(rcfw, cookie, opcode);
> if (rc) {
> /* timed out */
> dev_err(&rcfw->pdev->dev, "cmdq[%#x]=%#x timedout (%d)msec\n",
> @@ -796,6 +836,7 @@ void bnxt_qplib_rcfw_stop_irq(struct bnxt_qplib_rcfw *rcfw, bool kill)
> kfree(creq->irq_name);
> creq->irq_name = NULL;
> creq->requested = false;
> + atomic_set(&rcfw->rcfw_intr_enabled, 0);
> }
>
> void bnxt_qplib_disable_rcfw_channel(struct bnxt_qplib_rcfw *rcfw)
> @@ -857,6 +898,7 @@ int bnxt_qplib_rcfw_start_irq(struct bnxt_qplib_rcfw *rcfw, int msix_vector,
> creq->requested = true;
>
> bnxt_qplib_ring_nq_db(&creq->creq_db.dbinfo, res->cctx, true);
> + atomic_inc(&rcfw->rcfw_intr_enabled);
>
> return 0;
> }
> diff --git a/drivers/infiniband/hw/bnxt_re/qplib_rcfw.h b/drivers/infiniband/hw/bnxt_re/qplib_rcfw.h
> index b7bbbae..089e616 100644
> --- a/drivers/infiniband/hw/bnxt_re/qplib_rcfw.h
> +++ b/drivers/infiniband/hw/bnxt_re/qplib_rcfw.h
> @@ -221,6 +221,7 @@ struct bnxt_qplib_rcfw {
> u64 oos_prev;
> u32 init_oos_stats;
> u32 cmdq_depth;
> + atomic_t rcfw_intr_enabled;
> struct semaphore rcfw_inflight;
> };
>
> --
> 2.5.5
>
next prev parent reply other threads:[~2023-06-12 7:40 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
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 [this message]
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=20230612070417.GO12152@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.