<div dir="ltr">Hi Folks,<div><br></div><div>For the GNI provider we could implement srx context.  Basically you'd end up binding the tag matching engine to multiple endpoints.   But we are quite busy getting the GNI provider ready for 1.5 release and KNL optimizations so I doubt we'd have cycles to implement srx context in time for the 1.5 release. We may have cycles to implement for a 1.6 release if there's a compelling use case.</div><div><br></div><div>For now, you'd probably be better of with the GNI provider using FI_EP_RDM and the AV.  </div><div><br></div><div>Howard</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">2017-02-28 15:52 GMT-07:00 Biddiscombe, John A. <span dir="ltr"><<a href="mailto:biddisco@cscs.ch" target="_blank">biddisco@cscs.ch</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">><br>
    Do you need to use connected endpoints, or would reliable-connected work for your app?<br>
  <<br>
<br>
</span>I don’t know the answer to that question. I always used verbs connected endpoint in the past and I wanted to get my libfabric conversion running essentially the same. Once I have it running my plan was to explore new features.<br>
<br>
Did you mean unconnected endpoints?<br>
<br>
I was planning on experimenting with unconnected endpoints, but need to look into setting up the AV. Once I master that, then in principle, I would be very happy to use unconnected endpoints. I don’t see that managing N endpoints buys much and the idea of not having hem is appealing. Do they solve the problem of shared receive buffers?<br>
<br>
Thanks<br>
<br>
JB<br>
<br>
</blockquote></div><br></div>