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?
This was directed to the proposal in the patch set,
ib_device->kverbs_provider is really not a great design choice for
and interface..
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.
I don't know either, but I was merely arguing that that this matter is
not kverbs specific, hence the interface should not reflect it as such.
The saner thing to do is to use UDP and one of
the high speed ethernet packet processing flavours available these
days.
AFAICT we still have a long way before an application can actually do
termination + zcopy with whats available today. Forwarding is more
reasonable, I agree.
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?
I'm not sure, but its seems slightly odd to me that the vast majority
of RDMA use cases is probably not our ulps (as much as I'd like them to
be ;)) but we state them as the bar.
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.
Well, I agree that UD is kind of a low bar, and probably most of the
value of the EFA device comes from their SRD transport.
Is usnic a burdan is because its not actively maintained in a subsystem
that is constantly evolving, or because it implements a small subset of
an RDMA device functionality?
Personally, given that most of RDMA usage lives in userland, I would
think that having a uverbs provider is a more appropriate bar than
supporting our kernel consumers. But I (like you and others) would be
more than happy seeing both supported.
Both can be set as a bar, but one could argue that its an unnecessarily
high bar (if its user-base has no interest in running our kernel
consumers).
The EFA device doesn't support rkeys: it *clearly* doesn't do the
thing we call RDMA.
A lot of applications don't use rkeys. We even have a kernel consumer
that don't use rkeys (9p) but still is using RDMA devices.
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.
I was referring to datagram rsockets...
