Re: [PATCH rdma-next 00/13] Elastic Fabric Adapter (EFA) driver

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 12/5/2018 12:00 PM, Jason Gunthorpe wrote:
On Wed, Dec 05, 2018 at 11:28:39AM -0500, Dennis Dalessandro wrote:

The question here is if we should even allow drivers under
drivers/infiniband that don't even implement common verbs, like usnic.

I would have been on board with that in the past but these days I'm not so
sure. I would like to see us moving away from an "infiniband" subsystem to
an "rdma" subsystem and embrace other technologies. We really do need to
rename the subsystem at some point.

The counterpoint is that a 'RDMA' subsystem is not just 'expose some
DMA queues to user space and let userspace sort it all out'.

It is a valid point. I'm not saying just expose some DMA queues, there has to be a valid, well thought out API.

That is properly called vfio, or perhaps matches this WarpDrive thing
Kenneth was trying to build.

As far as usnic, it seems like its the driver that has been forgotten about.
I see 3 commits in 2018. I'm not saying it's important or not, that's
another debate for another thread.

There are alot more than three, and all of them are from non-Cisco
people trying to maintain this driver. Many are mine.

This is not a plus, it shows why this approach is a burden on the rest
of the community.

That's the point I was beating around the bush about. As a community we don't need any fire and forget drivers where it gets upstreamed and abandoned.

But for the EFA driver I'm happy to see it. I say treat this as RFC for now
until we see a libfabric or kernel ULP, or even some other open and
available user space solution.

A non-verbs kernel ULP to a RDMA driver??? That is an entirely
different and less happy discussion!

Agree, but a valid discussion. However there isn't anything like that on the table here so not a rat hole we need to go down right now.

subsystems exist to put common things under. They are not a marketing
term. If a driver doesn't use the subsystem's support code, or
implement the subsystems APIs, why should it be in the subsystem?

Why should we be against the subsystem evolving though? I'm not saying we allow just anything, just that we leave it open for discussion, *if* something comes up.

Now if we do want to say a driver must support verbs it can't be wishy-washy. We should specify exactly the set of verbs that must be supported. The IBTA has the notion of some mandatory verbs right, so should that be the low bar? Should we whittle that down further? Perhaps to the point where there is enough support for the core to manage the device from a high level, and bigger picture things like SELinux and containers, but leave the data path up to the driver/userspace to go figure out?

-Denny




[Index of Archives]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Photo]     [Yosemite News]     [Yosemite Photos]     [Linux Kernel]     [Linux SCSI]     [XFree86]

  Powered by Linux