On Tue, Sep 22, 2020 at 07:30:32PM +0300, Gal Pressman wrote: > On 22/09/2020 19:14, Jason Gunthorpe wrote: > > On Tue, Sep 22, 2020 at 03:46:29PM +0300, Gal Pressman wrote: > > > >> I agree, that makes sense. > >> But assuming Oded actually goes and implements all the needed verbs to get a > >> basic functional libibverbs provider (assuming their HW can do it somehow), is > >> it really useful if no one is going to use it? > >> It doesn't sound like habanalabs want people to use GAUDI as an RDMA adapter, > >> and I'm assuming the only real world use case is going to be using the hl stack, > >> which means we're left with a lot of dead code that's not used/tested by anyone. > >> > >> Genuine question, wouldn't it be better if they only implement what's actually > >> going to be used and tested by their customers? > > > > The general standard for this 'accel' hardware, both in DRM and RDMA > > is to present an open source userspace. Companies are encouraged to > > use that as their main interface but I suppose are free to carry the > > cost of dual APIs, and the community's wrath if they want. > > I didn't mean they should maintain two interfaces. > The question is whether they should implement libibverbs support that covers the > cases used by their stack, or should they implement all "mandatory" verbs so > they could be able to run libibverbs' examples/perftest/pyverbs as well, even > though these will likely be the only apps covering these verbs. As I said, the minimum standard is an open source user space that will operate the NIC. For EFA we decided that was ibv_ud_pingpong, and now parts of pyverbs. A similar decision would be needed here too. It is a conversation that should start with a propsal from Oded. The *point* is to have the open userspace, so I really don't care what their proprietary universe does, and shrinking the opensource side becuase it is "redundant" is completely backwards to what we want to see. Jason
