On Sun, Dec 23, 2018 at 05:14:34PM +0200, Gal Pressman wrote: > I'd really like to get to a point where we know how our next > submission is going to look like. I understand that the lack of user > code accompanied to the driver is an issue - that won't be the case > in my next submission. Well, your submission is up to you :) There seems to have been quite a lot missing from the first go around, so I think you'll get more comments. You definitely need some kind of userspace though, we are not merging any kernel uapi stuff without some kind of userspace. > As I said, my proposal is to add libibverbs support (with standard > QPT_UD and QP states) and specification for SRD. In addition, I can > come up with an RFC for hiding EFA from in-kernel API as you > suggested, although we will probably revisit this in the future. > Will this be acceptable? I have a feeling EFA will hit the same problems as usnic - libibverbs will be difficult to extend to expose the various special things (how will AH's even work? What about MTU?). Although we are in a better place now, so maybe those problems are now solvable. Unless the libfabric EFA provider will use libibverbs for the kernel interface I'm not sure I see the point in making something for libibverbs that no-one is expected to use?? Jason
