On 05-Jan-19 03:04, Sagi Grimberg wrote: > >>>>> Are there any mandatory callbacks that EFA refuses other than this one >>>>> (which Gal said that it will support)? >>>> >>>> All the EOPNOTSUPP ones. It *really* doesn't support kverbs at >>>> all. >>> >>> Oh wow, didn't realize that :) >> >> Make the dicussion take a different light, doesn't it :) > > It sorta makes sense for efa I guess.. > >>>> Which is why my first thought was to just not present it via the >>>> in-kernel client API at all. >>> >>> Definitely, it should not appear to the client API at all.. >>> This patch is needed most definitely. >> >> Okay, Gal should keep going on that then, and do something about the >> mandatory verbs. Probably failing mandatory verbs tests should hide >> the driver from the client API (except toward uverbs). Will do. >> >>> I'm sure that all of those (other than modify_qp) are trivial >>> to add but it doesn't really make sense to have them if userspace >>> is not using uverbs for them. >> >> If there is no modify_qp then the driver doesn't support the verbs QP >> FSM, and a lot of other stuff. Ie it is not really a verbs QP. :\ > > Can you explain what does the FSM matter to UD? I always thought > its really just a shim because its sort of irrelevant... That's what I thought as well, but as I said, we'll implement the UD state transitions. > > If that is the case, EFA can implement a trivial modify_qp for > UD QPs (i.e. do nothing, but at least fit the interface)? > >>>> Only req_notify really extends into userspace verbs though. >>> >>> Is it? ibv_notify_cq doesn't go to the kernel afair.. >> >> There is a IB_USER_VERBS_CMD_REQ_NOTIFY_CQ .. >> >> Hmm.. Many drivers do this via a BAR page write, not via the syscall, >> so I guess we don't know if EFA needs this or not. > > I'm betting that it doesn't... Probably not, but I'll have to take a closer look.
