linux-rdma.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Zhu Yanjun <zyjzyj2000@gmail.com>
To: "lizhijian@fujitsu.com" <lizhijian@fujitsu.com>
Cc: Jason Gunthorpe <jgg@ziepe.ca>, Leon Romanovsky <leon@kernel.org>,
	RDMA mailing list <linux-rdma@vger.kernel.org>,
	"yangx.jy@fujitsu.com" <yangx.jy@fujitsu.com>,
	Bob Pearson <rpearsonhpe@gmail.com>,
	LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] RDMA/RXE: Add send_common_ack() helper
Date: Mon, 1 Aug 2022 15:47:55 +0800	[thread overview]
Message-ID: <CAD=hENfZN43c4ZBmXwdru61=341bZgfYa8VJeKaBQYF5KKFA2A@mail.gmail.com> (raw)
In-Reply-To: <b47219be-b6e0-9a18-5d84-5546c08d721e@fujitsu.com>

On Mon, Aug 1, 2022 at 3:28 PM lizhijian@fujitsu.com
<lizhijian@fujitsu.com> wrote:
>
>
>
> On 01/08/2022 15:11, Zhu Yanjun wrote:
> > On Mon, Aug 1, 2022 at 2:16 PM Li Zhijian <lizhijian@fujitsu.com> wrote:
> >> Most code in send_ack() and send_atomic_ack() are duplicate, move them
> >> to a new helper send_common_ack().
> >>
> >> In newer IBA SPEC, some opcodes require acknowledge with a zero-length read
> >> response, with this new helper, we can easily implement it later.
> >>
> >> Signed-off-by: Li Zhijian <lizhijian@fujitsu.com>
> >> ---
> >>   drivers/infiniband/sw/rxe/rxe_resp.c | 43 ++++++++++++++----------------------
> >>   1 file changed, 17 insertions(+), 26 deletions(-)
> >>
> >> diff --git a/drivers/infiniband/sw/rxe/rxe_resp.c b/drivers/infiniband/sw/rxe/rxe_resp.c
> >> index b36ec5c4d5e0..4c398fa220fa 100644
> >> --- a/drivers/infiniband/sw/rxe/rxe_resp.c
> >> +++ b/drivers/infiniband/sw/rxe/rxe_resp.c
> >> @@ -1028,50 +1028,41 @@ static enum resp_states do_complete(struct rxe_qp *qp,
> >>                  return RESPST_CLEANUP;
> >>   }
> >>
> >> -static int send_ack(struct rxe_qp *qp, u8 syndrome, u32 psn)
> >> +
> >> +static int send_common_ack(struct rxe_qp *qp, u8 syndrome, u32 psn,
> > The function is better with rxe_send_common_ack?
> I'm not clear the exact rule about the naming prefix. if it has, please let me know :)
>
> IMHO, if a function is either a public API(export function) or a callback to a upper layer,  it's a good idea to a fixed prefix.
> Instead, if they are just static, no prefix is not too bad.

When debug, a rxe_ prefix can help us filter the functions whatever
the function static or public.

>
> BTW, current RXE are mixing the two rules, it should be another standalone patch to do the cleanup if needed.

Yes. Please make this standalone patch to complete this.

Thanks and Regards,
Zhu Yanjun

>
> Thanks
> Zhijian
>
>
> > So when debug, rxe_ prefix can help us.
> >
> >> +                                 int opcode, const char *msg)
> >>   {
> >> -       int err = 0;
> >> +       int err;
> >>          struct rxe_pkt_info ack_pkt;
> >>          struct sk_buff *skb;
> >>
> >> -       skb = prepare_ack_packet(qp, &ack_pkt, IB_OPCODE_RC_ACKNOWLEDGE,
> >> -                                0, psn, syndrome);
> >> -       if (!skb) {
> >> -               err = -ENOMEM;
> >> -               goto err1;
> >> -       }
> >> +       skb = prepare_ack_packet(qp, &ack_pkt, opcode, 0, psn, syndrome);
> >> +       if (!skb)
> >> +               return -ENOMEM;
> >>
> >>          err = rxe_xmit_packet(qp, &ack_pkt, skb);
> >>          if (err)
> >> -               pr_err_ratelimited("Failed sending ack\n");
> >> +               pr_err_ratelimited("Failed sending %s\n", msg);
> >>
> >> -err1:
> >>          return err;
> >>   }
> >>
> >> -static int send_atomic_ack(struct rxe_qp *qp, u8 syndrome, u32 psn)
> >> +static int send_ack(struct rxe_qp *qp, u8 syndrome, u32 psn)
> > rxe_send_ack
> >
> >>   {
> >> -       int err = 0;
> >> -       struct rxe_pkt_info ack_pkt;
> >> -       struct sk_buff *skb;
> >> -
> >> -       skb = prepare_ack_packet(qp, &ack_pkt, IB_OPCODE_RC_ATOMIC_ACKNOWLEDGE,
> >> -                                0, psn, syndrome);
> >> -       if (!skb) {
> >> -               err = -ENOMEM;
> >> -               goto out;
> >> -       }
> >> +       return send_common_ack(qp, syndrome, psn,
> >> +                       IB_OPCODE_RC_ACKNOWLEDGE, "ACK");
> >> +}
> >>
> >> -       err = rxe_xmit_packet(qp, &ack_pkt, skb);
> >> -       if (err)
> >> -               pr_err_ratelimited("Failed sending atomic ack\n");
> >> +static int send_atomic_ack(struct rxe_qp *qp, u8 syndrome, u32 psn)
> > rxe_send_atomic_ack
> >
> > Thanks and Regards,
> > Zhu Yanjun
> >> +{
> >> +       int ret = send_common_ack(qp, syndrome, psn,
> >> +                       IB_OPCODE_RC_ATOMIC_ACKNOWLEDGE, "ATOMIC ACK");
> >>
> >>          /* have to clear this since it is used to trigger
> >>           * long read replies
> >>           */
> >>          qp->resp.res = NULL;
> >> -out:
> >> -       return err;
> >> +       return ret;
> >>   }
> >>
> >>   static enum resp_states acknowledge(struct rxe_qp *qp,
> >> --
> >> 1.8.3.1
> >>

  reply	other threads:[~2022-08-01  7:48 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-08-01  6:23 [PATCH] RDMA/RXE: Add send_common_ack() helper Li Zhijian
2022-08-01  7:11 ` Zhu Yanjun
2022-08-01  7:28   ` lizhijian
2022-08-01  7:47     ` Zhu Yanjun [this message]
2022-08-02  5:52       ` lizhijian
2022-08-02 13:17         ` Yanjun Zhu
2022-09-26 17:28 ` Jason Gunthorpe

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='CAD=hENfZN43c4ZBmXwdru61=341bZgfYa8VJeKaBQYF5KKFA2A@mail.gmail.com' \
    --to=zyjzyj2000@gmail.com \
    --cc=jgg@ziepe.ca \
    --cc=leon@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-rdma@vger.kernel.org \
    --cc=lizhijian@fujitsu.com \
    --cc=rpearsonhpe@gmail.com \
    --cc=yangx.jy@fujitsu.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).