On Thu, May 16, 2019 at 03:39:10PM +0000, Bernard Metzler wrote:
>
> >To: "Doug Ledford" <dledford@xxxxxxxxxx>
> >From: "Jason Gunthorpe" <jgg@xxxxxxxx>
> >Date: 05/07/2019 06:13PM
> >Cc: "linux-rdma" <linux-rdma@xxxxxxxxxxxxxxx>, "Bernard Metzler"
> ><BMT@xxxxxxxxxxxxxx>
> >Subject: Re: iWARP and soft-iWARP interop testing
> >
> >On Mon, May 06, 2019 at 04:38:27PM -0400, Doug Ledford wrote:
> >> So, Jason and I were discussing the soft-iWARP driver submission,
> >and he
> >> thought it would be good to know if it even works with the various
> >iWARP
> >> hardware devices. I happen to have most of them on hand in one
> >form or
> >> another, so I set down to test it. In the process, I ran across
> >some
> >> issues just with the hardware versions themselves, let alone with
> >soft-
> >> iWARP. So, here's the results of my matrix of tests. These aren't
> >> performance tests, just basic "does it work" smoke tests...
> >
> >Well, lets imagine to merge this at 5.2-rc1?
> >
> >Bernard you'll need to rebase and resend when it comes out in two
> >weeks.
> >
> >Thanks,
> >Jason
> >
> >
> I think I addressed all major issues of the current siw RFC.
>
> Probably most important, it's now guaranteed that the remaining
> two objects (QP and MR) are kfree'd after return from the
> ib_devices free call. This makes it easier for future development
> of mid layers resource management, as Leon was pointing out.
>
> All IDR usage is gone as well.
>
> I removed the siw protection domain, since there is nothing
> siw specific to be stored within. I just keep a structure
> definition of 'struct siw_pd {struct ib_pd *base_pd}' to
> keep INIT_RDMA_OBJ_SIZE() happy.
? Really? I iwarp doesn't use a protection domain?
> Please advise what I shall do next to keep it going. Shall
> I send another RFC or rebase/resend it to current for-next
> now?
Rebase it when rc1 comes out and resend as not an RFC
Jason
