All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jason Gunthorpe <jgg@nvidia.com>
To: "Daisuke Matsuda (Fujitsu)" <matsuda-daisuke@fujitsu.com>,
	"rpearsonhpe@gmail.com" <rpearsonhpe@gmail.com>
Cc: 'Zhu Yanjun' <yanjun.zhu@linux.dev>,
	"linux-rdma@vger.kernel.org" <linux-rdma@vger.kernel.org>,
	"leon@kernel.org" <leon@kernel.org>,
	"zyjzyj2000@gmail.com" <zyjzyj2000@gmail.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"Xiao Yang (Fujitsu)" <yangx.jy@fujitsu.com>,
	"Zhijian Li (Fujitsu)" <lizhijian@fujitsu.com>,
	"Yasunori Gotou (Fujitsu)" <y-goto@fujitsu.com>
Subject: Re: [PATCH for-next v7 0/7] On-Demand Paging on SoftRoCE
Date: Thu, 4 Jan 2024 10:56:29 -0400	[thread overview]
Message-ID: <20240104145629.GY50406@nvidia.com> (raw)
In-Reply-To: <OS3PR01MB98659C7691D5DFB98D98D2BDE58BA@OS3PR01MB9865.jpnprd01.prod.outlook.com>

On Thu, Dec 07, 2023 at 06:37:13AM +0000, Daisuke Matsuda (Fujitsu) wrote:
> On Tue, Dec 5, 2023 10:51 AM Zhu Yanjun wrote:
> > 
> > 在 2023/12/5 8:11, Jason Gunthorpe 写道:
> > > On Thu, Nov 09, 2023 at 02:44:45PM +0900, Daisuke Matsuda wrote:
> > >>
> > >> Daisuke Matsuda (7):
> > >>    RDMA/rxe: Always defer tasks on responder and completer to workqueue
> > >>    RDMA/rxe: Make MR functions accessible from other rxe source code
> > >>    RDMA/rxe: Move resp_states definition to rxe_verbs.h
> > >>    RDMA/rxe: Add page invalidation support
> > >>    RDMA/rxe: Allow registering MRs for On-Demand Paging
> > >>    RDMA/rxe: Add support for Send/Recv/Write/Read with ODP
> > >>    RDMA/rxe: Add support for the traditional Atomic operations with ODP
> > >
> > > What is the current situation with rxe? I don't recall seeing the bugs
> > > that were reported get fixed?
> 
> Well, I suppose Jason is mentioning "blktests srp/002 hang".
> cf. https://lore.kernel.org/linux-rdma/dsg6rd66tyiei32zaxs6ddv5ebefr5vtxjwz6d2ewqrcwisogl@ge7jzan7dg5u/T/
> 
> It is likely to be a timing issue. Bob reported that "siw hangs with the debug kernel",
> so the hang looks not specific to rxe.
> cf. https://lore.kernel.org/all/53ede78a-f73d-44cd-a555-f8ff36bd9c55@acm.org/T/
> I think we need to decide whether to continue to block patches to rxe since nobody has successfully fixed the issue.

Bob? Is that what we think?

> There is another issue that causes kernel panic.
> [bug report][bisected] rdma_rxe: blktests srp lead kernel panic with 64k page size
> cf. https://lore.kernel.org/all/CAHj4cs9XRqE25jyVw9rj9YugffLn5+f=1znaBEnu1usLOciD+g@mail.gmail.com/T/

This is more understandable, and the fix of matching the MTT size to
the PAGE_SIZE seems reasonable to me.

Jason

      parent reply	other threads:[~2024-01-04 14:56 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-11-09  5:44 [PATCH for-next v7 0/7] On-Demand Paging on SoftRoCE Daisuke Matsuda
2023-11-09  5:44 ` [PATCH for-next v7 1/7] RDMA/rxe: Always defer tasks on responder and completer to workqueue Daisuke Matsuda
2023-11-09  5:44 ` [PATCH for-next v7 2/7] RDMA/rxe: Make MR functions accessible from other rxe source code Daisuke Matsuda
2023-11-09  5:44 ` [PATCH for-next v7 3/7] RDMA/rxe: Move resp_states definition to rxe_verbs.h Daisuke Matsuda
2023-11-09  5:44 ` [PATCH for-next v7 4/7] RDMA/rxe: Add page invalidation support Daisuke Matsuda
2023-11-09  5:44 ` [PATCH for-next v7 5/7] RDMA/rxe: Allow registering MRs for On-Demand Paging Daisuke Matsuda
2023-11-09 18:49   ` kernel test robot
2023-11-09  5:44 ` [PATCH for-next v7 6/7] RDMA/rxe: Add support for Send/Recv/Write/Read with ODP Daisuke Matsuda
2023-11-09  5:44 ` [PATCH for-next v7 7/7] RDMA/rxe: Add support for the traditional Atomic operations " Daisuke Matsuda
2023-12-05  0:11 ` [PATCH for-next v7 0/7] On-Demand Paging on SoftRoCE Jason Gunthorpe
2023-12-05  1:50   ` Zhu Yanjun
2023-12-07  6:37     ` Daisuke Matsuda (Fujitsu)
2023-12-12 18:07       ` Zhu Yanjun
2023-12-14  5:55         ` Daisuke Matsuda (Fujitsu)
2023-12-15  2:46           ` Zhu Yanjun
2024-01-04 14:56       ` Jason Gunthorpe [this message]

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=20240104145629.GY50406@nvidia.com \
    --to=jgg@nvidia.com \
    --cc=leon@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-rdma@vger.kernel.org \
    --cc=lizhijian@fujitsu.com \
    --cc=matsuda-daisuke@fujitsu.com \
    --cc=rpearsonhpe@gmail.com \
    --cc=y-goto@fujitsu.com \
    --cc=yangx.jy@fujitsu.com \
    --cc=yanjun.zhu@linux.dev \
    --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 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.