From: Jason Gunthorpe <jgg@nvidia.com>
To: Bob Pearson <rpearsonhpe@gmail.com>
Cc: "Daisuke Matsuda (Fujitsu)" <matsuda-daisuke@fujitsu.com>,
"zyjzyj2000@gmail.com" <zyjzyj2000@gmail.com>,
"leon@kernel.org" <leon@kernel.org>,
"jhack@hpe.com" <jhack@hpe.com>,
"ian.ziemba@hpe.com" <ian.ziemba@hpe.com>,
"lizhijian@fujitsu.com" <lizhijian@fujitsu.com>,
"haris.phnx@gmail.com" <haris.phnx@gmail.com>,
"linux-rdma@vger.kernel.org" <linux-rdma@vger.kernel.org>
Subject: Re: [PATCH for-next v2 18/18] RDMA/rxe: Add parameters to control task type
Date: Tue, 25 Oct 2022 13:27:03 -0300 [thread overview]
Message-ID: <Y1gOV/RQH1o5LIGf@nvidia.com> (raw)
In-Reply-To: <d38b66a8-220e-811b-1d90-d0fa4598c695@gmail.com>
On Tue, Oct 25, 2022 at 09:31:25AM -0500, Bob Pearson wrote:
> On 10/25/22 06:18, Jason Gunthorpe wrote:
> > On Tue, Oct 25, 2022 at 09:35:01AM +0000, Daisuke Matsuda (Fujitsu) wrote:
> >> On Sat, Oct 22, 2022 5:01 AM Bob Pearson:
> >>>
> >>> Add modparams to control the task types for req, comp, and resp
> >>> tasks.
> >>>
> >>> It is expected that the work queue version will take the place of
> >>> the tasklet version once this patch series is accepted and moved
> >>> upstream. However, for now it is convenient to keep the option of
> >>> easily switching between the versions to help benchmarking and
> >>> debugging.
> >>>
> >>> Signed-off-by: Ian Ziemba <ian.ziemba@hpe.com>
> >>> Signed-off-by: Bob Pearson <rpearsonhpe@gmail.com>
> >>> ---
> >>> drivers/infiniband/sw/rxe/rxe_qp.c | 6 +++---
> >>> drivers/infiniband/sw/rxe/rxe_task.c | 8 ++++++++
> >>> drivers/infiniband/sw/rxe/rxe_task.h | 4 ++++
> >>> 3 files changed, 15 insertions(+), 3 deletions(-)
> >>
> >> <...>
> >>
> >>> diff --git a/drivers/infiniband/sw/rxe/rxe_task.c b/drivers/infiniband/sw/rxe/rxe_task.c
> >>> index 9b8c9d28ee46..4568c4a05e85 100644
> >>> --- a/drivers/infiniband/sw/rxe/rxe_task.c
> >>> +++ b/drivers/infiniband/sw/rxe/rxe_task.c
> >>> @@ -6,6 +6,14 @@
> >>>
> >>> #include "rxe.h"
> >>>
> >>> +int rxe_req_task_type = RXE_TASK_TYPE_TASKLET;
> >>> +int rxe_comp_task_type = RXE_TASK_TYPE_TASKLET;
> >>> +int rxe_resp_task_type = RXE_TASK_TYPE_TASKLET;
> >>
> >> As the tasklet version is to be eliminated in near future, why
> >> don't we make the workqueue version default now?
> >
> > Why don't we just get rid of the tasklet version right away?
> >
> > Jason
>
> What time zone are you in? I thought you were out west.
>
> There are several users out there who use rxe as a dev tool for other subsystems.
> I don't want to make a big change that they can't control. By letting them decide
> if and when to move that is avoided. I could back out the modparam and just let
> people recompile but I'd end up putting it back in for our use because it is easier.
As long as it is functionally the same I'm not worried about
this. Small performance variations are not going to effect dev work.
> No matter what we decide to do here, there is a question I have about how to
> surface tuning parameters to users. Not everyone can just recompile to make changes.
> What is the preferred way to do this?
I don't know that we have much in this area pre-existing. Most of the
devices do not seem to have tuning?
sysfs and rdma netlink are the usual answers, but I don't know about
exposing rxe specific tunables in netlink..
Jason
next prev parent reply other threads:[~2022-10-25 16:27 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-10-21 20:01 [PATCH v2 00/18] Implement work queues for rdma_rxe Bob Pearson
2022-10-21 20:01 ` [PATCH for-next v2 01/18] RDMA/rxe: Remove redundant header files Bob Pearson
2022-10-21 20:01 ` [PATCH for-next v2 02/18] RDMA/rxe: Remove init of task locks from rxe_qp.c Bob Pearson
2022-10-21 20:01 ` [PATCH for-next v2 03/18] RDMA/rxe: Removed unused name from rxe_task struct Bob Pearson
2022-10-21 20:01 ` [PATCH for-next v2 04/18] RDMA/rxe: Split rxe_run_task() into two subroutines Bob Pearson
2022-10-21 20:01 ` [PATCH for-next v2 05/18] RDMA/rxe: Make rxe_do_task static Bob Pearson
2022-10-21 20:01 ` [PATCH for-next v2 06/18] RDMA/rxe: Rename task->state_lock to task->lock Bob Pearson
2022-10-21 20:01 ` [PATCH for-next v2 07/18] RDMA/rxe: Make task interface pluggable Bob Pearson
2022-10-25 8:02 ` Daisuke Matsuda (Fujitsu)
2022-10-25 14:16 ` Bob Pearson
2022-10-21 20:01 ` [PATCH for-next v2 08/18] RDMA/rxe: Split rxe_drain_resp_pkts() Bob Pearson
2022-10-21 20:01 ` [PATCH for-next v2 09/18] RDMA/rxe: Simplify reset state handling in rxe_resp.c Bob Pearson
2022-10-21 20:01 ` [PATCH for-next v2 10/18] RDMA/rxe: Handle qp error " Bob Pearson
2022-10-21 21:22 ` kernel test robot
2022-10-21 20:01 ` [PATCH for-next v2 11/18] RDMA/rxe: Cleanup comp tasks in rxe_qp.c Bob Pearson
2022-10-21 20:01 ` [PATCH for-next v2 12/18] RDMA/rxe: Remove __rxe_do_task() Bob Pearson
2022-10-21 20:01 ` [PATCH for-next v2 13/18] RDMA/rxe: Make tasks schedule each other Bob Pearson
2022-10-21 20:01 ` [PATCH for-next v2 14/18] RDMA/rxe: Implement disable/enable_task() Bob Pearson
2022-10-21 20:01 ` [PATCH for-next v2 15/18] RDMA/rxe: Replace TASK_STATE_START by TASK_STATE_IDLE Bob Pearson
2022-10-21 20:01 ` [PATCH for-next v2 16/18] RDMA/rxe: Replace task->destroyed by task state INVALID Bob Pearson
2022-10-21 20:01 ` [PATCH for-next v2 17/18] RDMA/rxe: Add workqueue support for tasks Bob Pearson
2022-10-21 20:01 ` [PATCH for-next v2 18/18] RDMA/rxe: Add parameters to control task type Bob Pearson
2022-10-25 9:35 ` Daisuke Matsuda (Fujitsu)
2022-10-25 11:18 ` Jason Gunthorpe
2022-10-25 14:31 ` Bob Pearson
2022-10-25 16:27 ` Jason Gunthorpe [this message]
2022-10-25 14:49 ` Bob Pearson
2022-10-26 7:07 ` Daisuke Matsuda (Fujitsu)
2022-10-28 17:04 ` [PATCH v2 00/18] Implement work queues for rdma_rxe Jason Gunthorpe
2022-10-28 18:16 ` Bob Pearson
2022-10-28 18:17 ` Jason Gunthorpe
2022-10-28 18:58 ` Bob Pearson
2022-10-28 19:16 ` Jason Gunthorpe
2022-10-28 19:29 ` Pearson, Robert B
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=Y1gOV/RQH1o5LIGf@nvidia.com \
--to=jgg@nvidia.com \
--cc=haris.phnx@gmail.com \
--cc=ian.ziemba@hpe.com \
--cc=jhack@hpe.com \
--cc=leon@kernel.org \
--cc=linux-rdma@vger.kernel.org \
--cc=lizhijian@fujitsu.com \
--cc=matsuda-daisuke@fujitsu.com \
--cc=rpearsonhpe@gmail.com \
--cc=zyjzyj2000@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