[libfabric-users] [ofiwg] Shared Rx and Connected
jianxin.xiong at intel.com
Tue Sep 10 11:57:32 PDT 2019
One possibility is to define a new bit in the "flags" field of the returned CQ entries to indicate the source address is for connected endpoints.
> -----Original Message-----
> From: ofiwg <ofiwg-bounces at lists.openfabrics.org> On Behalf Of Doug
> Oucharek via ofiwg
> Sent: Monday, September 09, 2019 1:34 PM
> To: Hefty, Sean <sean.hefty at intel.com>
> Cc: ofiwg at lists.openfabrics.org; libfabric-users at lists.openfabrics.org
> Subject: Re: [ofiwg] [libfabric-users] Shared Rx and Connected
> > On Sep 9, 2019, at 1:18 PM, Hefty, Sean <sean.hefty at intel.com> 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
> >> Did you want me to create an issue on this to track it?
> > Yes, please.
> Will do.
> ofiwg mailing list
> ofiwg at lists.openfabrics.org
More information about the Libfabric-users