Re: [PATCH V7 libibverbs 0/7] Add extension and XRC QP support

[Yishai Hadas <yishaih-LDSdmyG8hGV8YrgS2mwiifqBs+8SCbDb@public.gmane.org>]

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 majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> 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 majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html