> On Sep 9, 2019, at 1:18 PM, Hefty, Sean <[email protected]> wrote:
> 
>> Longer term, it seems we could really use another fi_cq_readfrom() specific 
>> to
>> connected endpoints.  Rather than return an fi_addr_t, it should return a 
>> fid_ep
>> pointer.  It would be great to extend fi_cq_readfrom() with an extra 
>> parameter, but
>> that would break existing code so perhaps creating a new call would be best. 
>>  Something
>> like:
>> 
>> ssize_t fi_cq_readfromconn(struct fid_cq *cq, void *buf, size_t count,
>>    struct fid_eq **src_ep);
>> The local context could be retrieved from the context of the src_ep’s.
> 
> The problem is that CQs are not limited to a specific EP type.  
> Fi_cq_readfrom() uses
> 
>       fi_addr_t *src_addr
> 
> as the output parameter.  Fi_addr_t is uint64_t.  There might be a way to 
> make it work without breaking apps by returning a different pointer value if 
> the completion is associated with a connected EP.

Good point.  Did not think about that.  I like your suggestion of having a 
different pointer type based on whether we are connected or connectionless.  
The only problem: how to communicate which type of pointer it is per returned 
element?
> 
>> Did you want me to create an issue on this to track it?
> 
> Yes, please.

Will do.

_______________________________________________
ofiwg mailing list
[email protected]
https://lists.openfabrics.org/mailman/listinfo/ofiwg

Reply via email to