On Tue, Jan 01, 2019 at 04:27:51PM -0800, Sagi Grimberg wrote: > Its not that EFA does not support kverbs, isn't kverbs is an abstract > name for "what our current ulps require"? kverbs is an abstract name for "what our current ulps require" and EFA clearly doesn't support that.. What are you trying to say? > Why is this kernel specific anyways? The exact same holds for uverbs > applications that use RC, or in other words we can also see a kernel > consumer that use UD (and does not rely on IB addressing like ipoib) > that can run on the EFA device... We could but we don't have such a thing today.. .. and I'm not sure we ever will, as UD is kind of useless on an ethernet based network. The saner thing to do is to use UDP and one of the high speed ethernet packet processing flavours available these days. > And, fwiw, I'm not sure I understand why should a new device support our > kernel ulps (again, not kverbs, functionality required by our existing > kernel consumers) if its users are not interested in it (if it was the > case then it would probably be supported). So what is your standard for determining if a device is part of the RDMA subsystem or not? If we don't have 'implements kverbs' as a requriement, and just permit UD QP verbs as the baseline requirement, is that OK? (and again note the original EFA submission didn't even support UD QP verbs) This is where usnic is already. The EFA device doesn't support rkeys: it *clearly* doesn't do the thing we call RDMA. > Isn't it enough that something like rsockets can run on a device to > justify its existence? ?? rsockets requires RC RDMA QPs, EFA won't support it. Jason
