Hi Jason,
Let me clarify the place holder reservation mentioned in the cover letter.
The entries I was referring to are not proprietary vendor verbs but
rather user space
verbs who are on their way to be submitted upstream for inclusion in
libibverbs/libmlx4.
Two of these verbs are the userspace API for Flow-Steering whose kernel
part (as you know)
is under review in linux-rdma. These verbs are
ibv_create_flow/ibv_destroy_flow which
serve to attach and detach a QPs to/from flows, using flow
specification. The third
verb deals with registration of shared-memory, details below.
Each verb consumes two pointers, one for the verbs library code and one
for provider
specific library implementation, total of six pointers.
I think we all agree that the current milestone to meet w.r.t to verbs
extensions is
to have the basic extensions mechanism AND XRC patches merged.
On the other hand, RAW Ethernet QPs are merged upstream (kernel + user
space) but without
upstream mechanism to actually receive traffic on them which makes them
pretty much useless.
So in that respect, it would make sense for us as vendor to provide
customers through
mellanox ofed the means to use them. What asked now is to reserve the
pointers, no more.
As for the Shared-MR, indeed it would have been fair to require
submitting this
code prior to the pointer reservation, so for next time...
To sum up, we think it would be constructive step to continue with this
series while reserving the six pointers,
or if this really helps submit for review the libibverbs part of those
verbs along with the basic verbs extensions patches.
What do you think ?
By the way I'm OOO for a week starting 16/7.
Yishai
New verb, "Register Shared Memory Region”: this verb is defined in the
IB spec, section 11.2.8.8.
“Given an existing Memory Region, a new independent Memory Region
associated with the same physical memory locations is created by that
new verb.
Through repeated calls to the Verb, an arbitrary number of Memory
Regions can potentially share the same physical memory locations.
The memory region created by this verb behaves identically to memory
regions created by the other memory registration verbs.”
In general sharing MR involves 2 steps:
1) Using the regular mechanism to create a Memory Region, application
can mention that MR should be created with a later option to be shared.
The application will supply the allowed sharing access to that MR.
2) Using the “Register Shared MR” to register to the pre-allocated
shared MR.
On 7/11/2013 8:07 PM, Jason Gunthorpe wrote:
On Thu, Jul 11, 2013 at 06:04:16PM +0300, Yishai Hadas wrote:
ABI support with OFED release, added place holder for 6 function pointers
in verbs_context to enable ABI compatibility with OFED release that already
used 6 extended verbs before XRC.
WTF !?!
The extension mechanism is NOT A TOY.
IT IS NOT FOR VENDORS TO USE.
Extension ids must be allocated at upstream, by Roland.
If you deviate from upstream you *MUST* change the ibverbs SONAME.
PERIOD.
What version of OFA OFED did this? This is a violation of the new
upstream first policy at OFA!
So, I'm going to NAK this. It sets an exceedingly bad precedent going
forward.
Jason
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
