RE: Kernel fast memory registration API proposal [RFC]

["Steve Wise" <swise-7bPotxP6k4+P2YhJcF5u+vpXobYPEAuW@public.gmane.org>]

> -----Original Message-----
> From: Jason Gunthorpe [mailto:jgunthorpe-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org]
> Sent: Tuesday, July 14, 2015 12:08 PM
> To: Sagi Grimberg
> Cc: Christoph Hellwig; linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; Steve Wise; Or Gerlitz; Oren Duer; Chuck Lever; Bart Van Assche; Liran Liss;
Hefty,
> Sean; Doug Ledford; Tom Talpey
> Subject: Re: Kernel fast memory registration API proposal [RFC]
> 
> On Tue, Jul 14, 2015 at 07:46:50PM +0300, Sagi Grimberg wrote:
> > >I'm really disappointed by the negative emails on this subject..
> 
> > I'm really not trying to be negative. I'm hearing you out, and I agree
> > with a lot of what you have to say. I just don't agree with all of it.
> 
> Sure, I just find it hard to be constructive against "I don't like it" :)
> 
> > Which drivers doesn't support FRWR that we need to do other things?
> > ipath - depracated
> 
> We have permission to move this to staging and then RM it, so yay!
> 
> > mthca - soon to be deprecated
> 
> This one I have a problem with. There is alot of mthca hardware out
> there, it feels wrong to nuke it.. If we can continue to support the
> FMR scheme it uses transparently, that would be excellent.
> 
> I'm not hearing a strong reason why that shouldn't be the case...
> 
> > ehca - Not sure what is going on there. they only have phys_mr
> >        anyway, which just lost its only caller in the kernel
> 
> I thought it supported fmr:
> 
> drivers/infiniband/hw/ehca/ehca_main.c: shca->ib_device.alloc_fmr           = ehca_alloc_fmr;
> drivers/infiniband/hw/ehca/ehca_main.c: shca->ib_device.map_phys_fmr        = ehca_map_phys_fmr;
> drivers/infiniband/hw/ehca/ehca_main.c: shca->ib_device.unmap_fmr           = ehca_unmap_fmr;
> drivers/infiniband/hw/ehca/ehca_main.c: shca->ib_device.dealloc_fmr         = ehca_dealloc_fmr;
> 
> ?
> 
> I'm not sure what the status of ehca is, but I somehow suspect any
> remaining users are going to be on an old vendor kernel forever..
> 
> > amso1100 - git log shows almost zero activity with this driver
> 
> IIRC, this card was already/nearly discountinued and obsolete when the driver
> was added, I certainly wouldn't object to remove it, or totally break
> it for kernel storage ULPs - Steve?
>

We can remove it or stage it then remove.
 
> > usnic - who is completely not interesting to the kernel ULPs because:
> 
> Right.
> 
> > So my point is, it's a great deal of effort to combine these
> > in any API that we come up with for a bunch of esoteric drivers.
> > Let's just let them die on their own, please.
> 
> If amso110 is the only iWarp driver that needs phys_mr, I'd be happy
> to drop it and drop the requirement to support that. Is that right Steve?
> 


Yes.

> But mthca, I have a hard time calling that esoteric.. Heck, even I
> still have various mthca cards around here that are regularly used for
> SDR/DDR/CX4 testing on modern kernels..
> 
> Jason

--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html